aboutsummaryrefslogtreecommitdiff
path: root/source/eo
ModeNameSize
d---------accessibility / source33logplain
d---------android / sdremote / res35logplain
d---------avmedia / source33logplain
d---------basctl68logplain
d---------basic / source33logplain
d---------chart2 / source / controller33logplain
d---------connectivity68logplain
d---------cui68logplain
d---------dbaccess / source33logplain
d---------desktop68logplain
d---------dictionaries1787logplain
d---------editeng / source33logplain
d---------extensions / source33logplain
d---------filter68logplain
d---------forms / source33logplain
d---------formula / source33logplain
d---------fpicker / source33logplain
d---------framework / source33logplain
d---------helpcontent2 / source33logplain
d---------instsetoo_native / inc_openoffice / windows41logplain
d---------librelogo / source33logplain
d---------mysqlc70logplain
d---------nlpsolver61logplain
d---------officecfg / registry / data / org / openoffice35logplain
d---------padmin37logplain
d---------readlicense_oo35logplain
d---------reportbuilder101logplain
d---------reportdesign / source33logplain
d---------sc68logplain
d---------scaddins / source33logplain
d---------sccomp / source33logplain
d---------scp2 / source33logplain
d---------sd68logplain
d---------sdext / source33logplain
d---------setup_native / source33logplain
d---------sfx268logplain
d---------shell / source / win32 / shlxthandler33logplain
d---------starmath72logplain
d---------svl / source33logplain
d---------svtools68logplain
d---------svx67logplain
d---------sw68logplain
d---------swext / mediawiki36logplain
d---------sysui / desktop34logplain
d---------tubes / uiconfig35logplain
d---------uui37logplain
d---------vcl97logplain
d---------wizards / source33logplain
d---------xmlsecurity / source33logplain
generated by cgit (git 2.34.1) at 2025-01-24 00:44:00 +0000
n> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/check.cxx
AgeCommit message (Collapse)Author
2024-11-05Fix implementation of loplugin::isDerivedFromStephan Bergmann
...where clang::CXXRecordDecl::forallBases is documented as: "This routine returns false if the class has non-computable base classes." So, presumably since <https://github.com/llvm/llvm-project/commit/bf099f4682bf088aaa49b2c72fb1ef3250213fbb> "[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)" changed > -template <std::size_t I, typename ValueTy> > -struct tuple_element<I, llvm::StringMapEntry<ValueTy>> > - : std::conditional<I == 0, llvm::StringRef, ValueTy> {}; > +template <std::size_t Index, typename ValueTy> > +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>> > + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {}; in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here started to trivially always be true for that struct tuple_element specialization, so the isDerivedFrom check in CheckFileVisitor::VisitCXXRecordDecl in compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true for that struct, so it started to generate compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra > InfoVersion:1 > ClassName:tuple_element > InfoEnd content, which in turn caused the generated compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of > #include "tuple_element.cxx" and other nonsense, which caused the build to break with > [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx > lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found > 20 | #include "tuple_element.cxx" > | ^~~~~~~~~~~~~~~~~~~ etc. (And now spelling out the implementation of forAnyBase here also reveals that BaseCheckSubclass will never be called with a null BaseDefinition, so the code handling that has been removed.) Change-Id: I8a6e42260eae86852ec37a80d058777653fac394 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
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-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>
2022-04-05Simplify GlobalNamespace checkStephan Bergmann
Change-Id: Id70abc5d1ccdc41dc771fe77ad0e7584efe76826 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132569 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-04Fix GlobalNamespace checkStephan Bergmann
...so that e.g. building on F36 with -stdlib=libc++ doesn't fail with > i18nutil/source/utility/paper.cxx:311:75: error: NullToPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > locale_t loc = newlocale(LC_PAPER_MASK, "", static_cast<locale_t>(0)); > ^ when the locale_t typedef declaration is nested in extern "C" (from /usr/include/stdlib.h) which in turn is nested in extern "C++" (from LLVM's include/c++/v1/math.h) Change-Id: Ie81d7425cda231954bdbab47c3a0431dc7c27f5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132520 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>