summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/nullptr.cxx
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-12-18-Werror,-Wdeprecated-declarationsStephan Bergmann
> compilerplugins/clang/casttovoid.cxx:452:18: error: 'endswith' is deprecated: Use ends_with instead [-Werror,-Wdeprecated-declarations] > .endswith(".h")); > ^~~~~~~~ > ends_with > ~/llvm/inst/include/llvm/ADT/StringRef.h:276:19: note: 'endswith' has been explicitly marked deprecated here > [[nodiscard]] LLVM_DEPRECATED( > ^ etc. after <https://github.com/llvm/llvm-project/commit/5ac12951b4e9bbfcc5791282d0961ec2b65575e9> "[ADT] Deprecate StringRef::{starts,ends}with (#75491)" on Clang 18 trunk, where <https://github.com/llvm/llvm-project/commit/1b97645e56bf321b06d1353024339958b64fd242> "[ADT] Introduce StringRef::{starts,ends}_width{,_insensitive}" had been added towards Clang 16 Change-Id: Icb3e43b7d6be6f877815285913d846f766eddebf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160919 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2022-02-17Bump compiler plugins Clang baseline to 12.0.1Stephan Bergmann
...as discussed in the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2020-November/086234.html> "Bump --enable-compiler-plugins Clang baseline?" (and now picked up again at <https://lists.freedesktop.org/archives/libreoffice/2022-February/088459.html> "Re: Bump --enable-compiler-plugins Clang baseline?"), and clean up compilerplugins/clang/ accordingly Change-Id: I5e81c6fdcc363aeefd6227606225b526fdf7ac16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129989 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-15Let loplugin:nullptr look into template instantiationsStephan Bergmann
It missed some occurrences of 0 when only looking into uninstantiated template code, as Clang doesn't model them with an ImplicitCastExpr, even if the target is known to be a (dependent) pointer type. Looking into all template instantiations of course carries the risk that a given use of 0 is meant to be interpreted as a pointer in some and as an integer in other instantiations. But the only case where that happened in the current code base is RegistryValueList::getElement (include/registry/registry.hxx), where {} is arguably a better choice anyway. (And which would presumably also hold for any future such cases.) Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-08better name for a function in compilerpluginsLuboš Luňák
The function is not just about a spelling location. Change-Id: I96e9e9ef7e27a9763397b4b86473c1c30d0e3eeb Reviewed-on: https://gerrit.libreoffice.org/80381 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-07fix various warnings in compilerpluginsLuboš Luňák
These are triggered when using llvm-config --cxxflags for building, and sometimes there's -Werror. The warnings were mostly unused variables because of being used only in assert(), or default case in switch that covers all enums (it's better to not handle default to get warning if a case is not handled). Change-Id: I0ecdd1f27390aadf033852b0d1ee0ca424ae3c37 Reviewed-on: https://gerrit.libreoffice.org/80317 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-08-16Adapt loplugin:nullptr to RecursiveASTVisitior::TraverseInitListExpr changeStephan Bergmann
...<https://github.com/llvm/llvm-project/commit/ 0a42fe70a566f22599e04a6f1344ca2dc5565e17> "[AST] Treat semantic form of InitListExpr as implicit code in traversals" Change-Id: Ifd17009fcc6933abf0e9178dbe47fb9c14b274b7 Reviewed-on: https://gerrit.libreoffice.org/77595 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-14filter out some of the AST in the pluginsNoel Grandin
by checking if the current namespace decl is in our code, so we have to scan less stuff, which results in a 10% perf improvement for me Change-Id: Idf0e30d57b6d0dcd13daa9ed679c28b9d233d387 Reviewed-on: https://gerrit.libreoffice.org/58942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-10Avoid -Werror=deprecated-declarations with recent Clang trunkStephan Bergmann
...which first added alternative names to and then deprecated getLocBegin/End Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2 Reviewed-on: https://gerrit.libreoffice.org/58820 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-07-06compilerplugins: try to make these work with icecreamMichael Stahl
There are some problems here, this should fix one of them: the getFilename function returns "<stdin>" for spelling locations, because the input to clang is sort of preprocessed via -frewrite-includes if icecream is used and the file is built on a remote host (whereas it's apparently not preprocessed if the file is compiled locally by icecream). Using getPresumedLoc() uses the #line directives in the preprocessed input, which avoids the problem but is more expensive, so try to use it only when necessary. The getFileEntry(getMainFileID())->getName() pattern will also result in "<stdin>", but fortunately icecream passes -main-file-name, which oddly enough isn't used by the SourceManager's spelling locations, but is available separately via CodeGenOptions. This builds everything successfully with clang version 6.0.0: ICECC_PREFERRED_HOST=myremote make check gb_SUPPRESS_TESTS=t Change-Id: Ic121511683e5302d7b9d85186c8b9c4a5443fa1b Reviewed-on: https://gerrit.libreoffice.org/54993 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-05-04Adapt to Clang trunk SourceManager::getImmediateExpansionRange changesStephan Bergmann
...of <http://llvm.org/viewvc/llvm-project?view=revision&revision=331155> "PR37189 Fix incorrect end source location and spelling for a split '>>' token", changing (among others) the return type of getImmediateExpansionRange from a std::pair of token locations to CharSourceRange (which will typically also represent token locations, but might also represent char locations). For now, map the return value of getImmediateExpansionRange back to a std::pair (as expected by our compilerplugins code in its current form), and mark the char location case with a TODO (which will need to be addressed if any of our plugins starts to produce wrong results due to not handling that char location case). In the long run, we should instead adapt our code to use the new return type of getImmediateExpansionRange directly. Change-Id: Idc2f5dc43830af4798b55bf605976c4ab146c522 Reviewed-on: https://gerrit.libreoffice.org/53817 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-07Clean away temporarily added using declarationsStephan Bergmann
Change-Id: I26734c13515394162d88351a1cbe2b20abdac865
2017-05-18Adapt pathname checks to mixed usage of \ and / on WindowsStephan Bergmann
Change-Id: I91bc89a9076c6642e06b238f65f2d31a1d20c6b5
2017-03-22Use nl_langinfo_l with an explicitly created localeStephan Bergmann
(where empty string arg to newlocale, per SUSv4, means "an implementation- defined native environment. This correspons to the value of the associated environment variables, LC_* and LANG") instead of relying on whatever setlocale would be in effect here. Also, nl_langinfo_l is less of an MT nightmare than nl_langinfo, which is of benefit once the last remaining use of nl_langinfo in sal/osl/unx/nlsupport.cxx will also have been changed to nl_langinfo_l. loplugin:nullptr needs a little hack, as SUSv4 locale_t could be anything from an integer type to a pointer type. Change-Id: Ic35dcbc2e0a4f650694b48df12470dd89476dff5
2016-10-07loplugin:nullptr: remove duplicate warningsStephan Bergmann
Change-Id: I859d9ac8f7e4134bdac59b39e95eb563d1291e8b
2016-07-11loplugin:nullptr: Better heuristic to determine code shared between C and C++Stephan Bergmann
Change-Id: I51e1c5fa4639e51fac90f92adf3d87d12960d589
2016-06-29Remove support for Clang < 3.4Stephan Bergmann
Change-Id: I81e97c5f720535b33dd3ce72d01151765e4e93a0
2016-06-29Remove support for Clang < 3.3Stephan Bergmann
Change-Id: I185852a738bac10dc6d331afccfcbc7ae1225cb1
2016-03-31loplugin:nullptr: Check for more pointer typesStephan Bergmann
(but did not turn up further matches) Change-Id: I7e4843d00a2e3b46edec46c5b56b6ba1b2e098fd
2016-03-30loplugin:nullptr: Find some more cases in templatesStephan Bergmann
Change-Id: I1f127d56e40b04f2b4df85c0afbcfd424d68a8cc
2016-02-26-Werror=return-typeStephan Bergmann
Change-Id: I44e627fa9de9c48a534cbc9ade6cc9d567553709
2016-02-26These version checks are about the Clang the plugins are built /against/Stephan Bergmann
...not the (Clang) compiler they are being built /with/. (Also simplifies the checking #if code.) Change-Id: I416321be4ef4478785be40571f81500fd3b6feb8
2016-01-06Enable loplugin:nullptrStephan Bergmann
I had it locally enabled for like a month now, and it did not produce any more noise than any of the other plugins. Change-Id: I94dab702c537969cf32922f6e88b4f5b503cd3f5
generated by cgit (git 2.34.1) at 2025-05-12 15:47:48 +0000