/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ /* * This file is part of the LibreOffice project. * * This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. * * This file incorporates work covered by the following license notice: * * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed * with this work for additional information regarding copyright * ownership. The ASF licenses this file to you under the Apache * License, Version 2.0 (the "License"); you may not use this file * except in compliance with the License. You may obtain a copy of * the License at http://www.apache.org/licenses/LICENSE-2.0 . */ #include namespace chart { OUString SchResId(TranslateId aId) { return Translate::get(aId, Translate::Create("chart")); } } // namespace chart /* vim:set shiftwidth=4 softtabstop=4 expandtab: */ tion> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/check.hxx
AgeCommit message (Collapse)Author
2024-02-07double operator < is not a strict weak ordering due to NaNStephan Bergmann
...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export2 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960 > 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268 > 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508 > 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528 > 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440 > 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728 > 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692 > 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288 But the introduced use of `std::strong_order(first[0], second[0]) < 0` then triggered a false > lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > 105 | return std::strong_order(first[0], second[0]) < 0; > | ^ so needed some hack in loplugin:nullptr. And old versions of libc++, still used at least on Android, do not have any implementations of std::strong_order. So detect those cases in configure.ac (checking for std::strong_order for double, which is what is actually being used in the code) and fall back to operator <=> for now, even if that will not provide a strict weak ordering and will thus continue to violate the requirements of std::sort. And then our venerable clang-format 5.0.0 would have broken the token `<=>` into `<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment. Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-06Adapt to various Clang 18 trunk enum reworkStephan Bergmann
<https://github.com/llvm/llvm-project/commit/a9070f22a29e28f7d6f83c24a8dd88f3a94969ae> "[clang][NFC] Refactor `CXXConstructExpr::ConstructionKind`", <https://github.com/llvm/llvm-project/commit/c23aaa410358b9f9c364ddaaeb6b2069b185a99b> "[clang][NFC] Refactor `CharacterLiteral::CharacterKind`", <https://github.com/llvm/llvm-project/commit/3e6ce58701a3a8463b53fb3fd2023c02b4e90554> "[clang][NFC] Refactor `StringLiteral::StringKind`", <https://github.com/llvm/llvm-project/commit/edd690b02e16e991393bf7f67631196942369aed> "[clang][NFC] Refactor `TagTypeKind` (#71160)" Change-Id: Ice802f6d662494781ad22fcf11ea5006de918254 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158983 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-20New loplugin:unoaggregationStephan Bergmann
"Find classes that derive from css::uno::XAggregation, but which implement queryInterface in violation of the protocol laid out in the documentation at udkapi/com/sun/star/uno/XAggregation.idl (which implies that such a class either doesn't actually make use of the deprecated XAggregation mechanism, which should thus be removed from that class hierarchy, or that its implementation of queryInterface needs to be fixed)." (compilerplugins/clang/unoaggregation.cxx) The basesHaveOnlyPureQueryInterface check in compilerplugins/clang/unoaggregation.cxx is "a crude approximation (but which appears to work OK)" to filter out any queryInterface base implementations of class hierarchies supporting XAggregation (i.e., cppu::OWeakAggObject::queryInterface). It only fails for the odd ChartDocumentWrapper::queryInterface, which manually implements the XAggregation functionality rather than (indirectly) deriving from OWeakAggObject. But changing that manual implementation looks tricky, so leave that alone for now and add a loplugin warning suppression there, and leave proper clean up for later. Change-Id: Ib16e26237bd703e60b0d9cb7134cb39840842d54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145912 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22Make namespace checks look through LinkageSpecsStephan Bergmann
My clang-cl --with-visual-studio=2022preview build against VS 2022 Preview 17.5.0 Preview 2.0 had started to fail with > [build CPT] compilerplugins/clang/test/getstr.cxx > error: 'error' diagnostics expected but not seen: > File compilerplugins/clang/test/getstr.cxx Line 42: directly use object of type '{{(rtl::)?}}OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr] > File compilerplugins/clang/test/getstr.cxx Line 48: directly use object of type 'S' (aka 'rtl::OString') in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr] > File compilerplugins/clang/test/getstr.cxx Line 49: directly use object of type 'rtl::OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr] > File compilerplugins/clang/test/getstr.cxx Line 55: directly use object of type 'rtl::OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr] > File compilerplugins/clang/test/getstr.cxx Line 57: directly use object of type '{{(rtl::)?}}OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr] > 5 errors generated. apparently because C:/Program Files/Microsoft Visual Studio/2022/Preview/VC/Tools/MSVC/14.35.32124/include/ostream now contains [...] > _EXPORT_STD extern "C++" template <class _Elem, class _Traits> > class basic_ostream : virtual public basic_ios<_Elem, _Traits> { // control insertions into a stream buffer [...] with a wrapping extern "C++", so the call to StdNamespace() in > if (!loplugin::TypeCheck(expr->getArg(0)->getType()) > .ClassOrStruct("basic_ostream") > .StdNamespace()) //TODO: check template args in compilerplugins/clang/getstr.cxx no longer matched Change-Id: Iaeb461d5aa855a8602c5c6f791407c08a1c5d309 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144735 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-04Improve loplugin:stringview detection of unnecessary O[U]String constructionStephan Bergmann
Change-Id: Ia45119e11377e916a1e1deb5648ed9033c417d77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107228 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-04tdf#124176 Use #pragma once in compilerpluginsGeorge Bateman
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: Id60579406a5aa16c3dc05a1bb5f1c1c828d39c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100251 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-07-02Improved loplugin:staticanonymous -> redundantstaticStephan Bergmann
...now also covering variables with internal linkage that don't need a redundant "static". (Unlike with functions, with variables there are also cases that are not in an unnamed namespace, hence the rename of the plugin.) All the relevant changes across the code base have been done in the preceding "Upcoming improved loplugin:staticanonymous -> redundantstatic" commits. Ideally the changes would have been done with a rewriting plugin, but it can be quite tedious in general to identify the correct occurrence of "static" that must be removed, consider e.g. struct { int init() { static int n; return n++; } int x = init(); } static const a[10] = {}; However, it turned out that in all cases across the code base, the relevant "static" was either at the start of the declaration or came after an initial "const". So I temporarily changed the plugin with > --- a/compilerplugins/clang/redundantstatic.cxx > +++ b/compilerplugins/clang/redundantstatic.cxx > @@ -59,7 +59,7 @@ class RedundantStatic > } > report( > DiagnosticsEngine::Warning, "redundant 'static' keyword in unnamed namespace", > - decl->getLocation()) > + decl->getBeginLoc()) > << decl->getSourceRange(); > return true; > } > @@ -73,7 +73,7 @@ class RedundantStatic > DiagnosticsEngine::Warning, > "non-inline variable of non-volatile const-qualified type is redundantly marked as" > " 'static'", > - decl->getLocation()) > + decl->getBeginLoc()) > << decl->getSourceRange(); > return true; > } to report the diagnostics at the start of the declarations (instead of at a more natural place which is typically somewhere in the middle of the declaration), compiled LO from within Emacs and then ran a function > (defun doit () > (interactive) > (while t > (next-error) > (with-current-buffer (window-buffer) > (when (re-search-forward > "\\=\\(\\<static\\>\\s *\\|\\(\\<const\\>\\)\\s +\\<static\\>\\)" > nil t) > (replace-match "\\2"))))) to do all the replacements. (Plus solenv/clang-format/reformat-formatted-files where necessary.) Change-Id: Ie7efc8e0593a407c390a6a7a08c81e547410f18a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97779 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14New loplugin:getstrStephan Bergmann
...to find matches of ... << s.getStr() (for the rtl string classes) that can be written as just ... << s Some notes: * The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in desktop/source/app/crashreport.cxx (even though that would also be done internally by the "<< OUString" operator) to clarify that these values are written out as UTF-8 (and not as what that operator << happens to use, which just also happens to be UTF-8). * OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now. * Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx. * The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just go, too. Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136 Reviewed-on: https://gerrit.libreoffice.org/80762 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-10Fix detection of std::unique_ptr/shared_ptr in loplugin:redundantpointeropsStephan Bergmann
...when the get member function is implemented in a base class, as happens for std::shared_ptr in libstdc++ (where it is implemented in base __shared_ptr; see also 7d361e96c9ea822790db21806e9fc05279423833 "loplugin:redundantpointerops"). And while at it, check for precisely the classes we are interested in (for which we know the semantics of get and operator*), rather than any classes whose unqualified names happen to match. Change-Id: I0c85ba46f191a2ee038c8175d979aa0c1be765cd Reviewed-on: https://gerrit.libreoffice.org/80585 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-13Avoid some false loplugin:redundantfcast involving std::function and lambdasStephan Bergmann
Change-Id: Id9a93fb60f957d75450deb93f1461b1d9dacf8ca Reviewed-on: https://gerrit.libreoffice.org/78860 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-28New loplugin:stdfunctionStephan Bergmann
...finding dubious additions to namespace std (concentrating on functions for now). C++17 [namespace.std]/1: "The behavior of a C ++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified." This found ad4c7b97752b4da73808402604d6f96b39d920f5 "Avoid declaring function templates in namespace std" 042e30a3dc057aef4a02d95960e4dd4fb8d083ae "Avoid adding a function template declaration to namespace std" cae9240a76cdb0eeed92421930d3b4cbef0ac201 "Avoid adding a function declaration to namespace std" Change-Id: Ic2ba54e2a8bf931d5c58cedf499c0d1229eb2166 Reviewed-on: https://gerrit.libreoffice.org/78220 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-06loplugin:typedefparam: Work around different size_t typedefs on macOSStephan Bergmann
...which for me caused > [CXX] registry/tools/options.cxx > /Users/stephan/Software/lo/core/registry/tools/options.cxx:39:89: error: function param 3 at definition site does not match function param at declaration site, 'size_t' (aka 'unsigned long') vs 'size_t' (aka 'unsigned long') [loplugin:typedefparam] > bool Options::checkArgument(std::vector< std::string> & rArgs, char const * arg, size_t len) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ > /Users/stephan/Software/lo/core/registry/tools/options.hxx:41:93: note: declaration site here [loplugin:typedefparam] > static bool checkArgument (std::vector< std::string > & rArgs, char const * arg, size_t len); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ because one is TypedefType 0x115a4d700 'size_t' sugar |-Typedef 0x115a4d460 'size_t' `-BuiltinType 0x7fde8e0393c0 'unsigned long' while the other is TypedefType 0x7fde8e94a3a0 'size_t' sugar |-Typedef 0x7fde8e94a138 'size_t' `-TypedefType 0x7fde8e94a100 '__darwin_size_t' sugar |-Typedef 0x7fde8e88cc28 '__darwin_size_t' `-BuiltinType 0x7fde8e0393c0 'unsigned long' and > [CXX] store/source/storcach.cxx > /Users/stephan/Software/lo/core/store/source/storcach.cxx:218:43: error: function param 1 at definition site does not match function param at declaration site, 'std::size_t' (aka 'unsigned long') vs 'std::size_t' (aka 'unsigned long') [loplugin:typedefparam] > void PageCache::rescale_Impl (std::size_t new_size) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~ > /Users/stephan/Software/lo/core/store/source/storcach.hxx:67:36: note: declaration site here [loplugin:typedefparam] > void rescale_Impl (std::size_t new_size); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~ because one is ElaboratedType 0x116f5cba0 'std::size_t' sugar `-TypedefType 0x7fd58673e090 'size_t' sugar |-Typedef 0x7fd58673dde8 'size_t' `-BuiltinType 0x7fd58603cfc0 'unsigned long' while the other is ElaboratedType 0x7fd586742200 'std::size_t' sugar `-TypedefType 0x7fd58621cdc0 'size_t' sugar |-Typedef 0x7fd5861ce4a0 'size_t' `-TypedefType 0x7fd5861cdc70 '__darwin_size_t' sugar |-Typedef 0x7fd586889ec8 '__darwin_size_t' `-BuiltinType 0x7fd58603cfc0 'unsigned long' Change-Id: I3622716376198cc046b0489db59c5cbf613ea1f4 Reviewed-on: https://gerrit.libreoffice.org/73585 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-12make (some) clang plugins share the same RecursiveASTVisitorLuboš Luňák
Each plugin currently uses its own recursive AST run, which adds up. This patch adds another shared plugin which internally contains all (suitable) plugins and dispatches to them from the same one recursive run. This patch converts ~25 plugins and for starmath's accessibility.cxx reduces clang build time from 5.43s to 5.14s (and it's 4.39s without any plugins). As there are almost 50 more plugins to go, this can theoretically result in 4.56s final time, although probably not all plugins can be that easily converted, if at all. This mostly requires very little change in many plugins (see e.g. BadStatics), some even work without any functionality change (e.g. CharRightShift). Traverse* calls require some changes but are often not that difficult. WalkUp* probably can't be supported, although some plugins can(?) possibly be adjusted to not rely on them. And of course some plugins can be left as they are, using their own recursive run. See description at the top of generator.cxx for description of how to convert a plugin. The sharedvisitor.cxx source is generated based on scanning relevant plugin sources using a clang-based scanner/generator. The generated source is intentionally included instead of getting always generated, as the generating currently takes some time, so it should get updated in git whenever a change in a plugin triggers a source change in it. Change-Id: Ia0d2e3a5a464659503dbb4ed6c20b6cc89b4de01 Reviewed-on: https://gerrit.libreoffice.org/68026 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-03-11move isDerivedFrom() from a clang plugin to shared code, for reuseLuboš Luňák
Change-Id: I7b9b41a7081281214a387cdf02080866e9b9dfe7 Reviewed-on: https://gerrit.libreoffice.org/68873 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>