summaryrefslogtreecommitdiff
path: root/solenv/CompilerTest_compilerplugins_clang.mk
AgeCommit message (Collapse)Author
2021-11-17retire loplugin:simplifyboolLuboš Luňák
The plugin was originally written to rewrite dumb old OOo code like 'variable != 1 ? true : false'. All that code has already been rewritten, and now this plugin just enforces matter-of-taste stylistics on new code. Change-Id: I8cd2accd7c0ac365b75dcba51a9049bf9e293869 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125346 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-17remove loplugin:finalprotectedLuboš Luňák
It just forces a custom rule that serves no real purpose. There's no technical difference. If one day a class gets inherited from then this information will be lost/incorrect. And mixing access on a virtual function is poor style. Change-Id: I0c27db8d694ad191a118d4e1d3d4a240e00456fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125337 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-10new loplugin:stringliteraldefineNoel Grandin
look for #define FOO "foo" that can be converted into OUStringLiteral. This is the first pass of this plugin, only doing those #define which are local to a single compilation unit. Change-Id: Ic8610e29ec42c36d03db5014a93c244315d5bbea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124962 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-02new loplugin:moveparamNoel Grandin
Look for places where we can pass Primitive2DContainer by move reference and so avoid unnecessary copies. Change-Id: I1db167feba6d1a616ca6fc39778118ae20106bd1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122964 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-13loplugin:cow_wrapperNoel Grandin
check the classes that use o3tl::cow_wrapper so that they don't unnecessarity trigger copies Change-Id: I545e627598217f3e61ba2c384adb8d4f8b404829 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122030 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-20New loplugin:unusedcapturedefaultStephan Bergmann
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building without --with-latest-c++) requires ROW_RANGE (a local const int variable from the enclosing TestFormula::testTdf97369) to be captured, even though all uses of that variable within the lambda body are constant expressions. That is still true at least for the latest Visual Studio 2019 version 16.11.1. (This is not an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down, as they, in addition to using that ROW_RANGE, also use the local const double variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so they are implicitly captured and loplugin:unusedcapturedefault does not suggest dropping those lambdas' capture-defaults in the first place.) Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-14new loplugin:weakobjectNoel Grandin
find classes with more than one copy of OWeakObject in their inheritance hierarchy, which is dodgy Change-Id: I4e31bd6db03d25d934b736bd6a9c1b665f976ee2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-22Clarify no loplugin:overridevirtual with templated base classStephan Bergmann
Change-Id: I4128b43f2a928fa5465991cc92b2d62e54e2cfec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-03throw() -> noexcept, part 3/3: New loplugin:noexceptStephan Bergmann
Change-Id: I3ce3fab3e8047be14e003f1f3096b4e2745534e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115026 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-03-01new loplugin:staticdynamicNoel
look for places we are dynamic_cast'ing after static_cast'ing, which means the dynamic_cast is a waste of time. Change-Id: Ife11bb675020738040646230bbd038278d84f7f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111631 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-12New loplugin:stringviewparamStephan Bergmann
...to "Find functions that take rtl::O[U]String parameters that can be generalized to take std::[u16]string_view instead." (Which in turn can avoid costly O[U]String constructions, see e.g. loplugin:stringview and subView.) Some of those functions' call sites, passing plain char string literals, needed to be adapted when converting them. Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-10new loplugin:reducevarscopeNoel Grandin
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-06retire the stringbuffer lopluginNoel
the best code is now the opposite of what this plugin recommends Change-Id: I88c04200c73a9bae07ef8fcf6ba5f1d9e4927709 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105394 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-09improve loplugin:unusedvarsglobalNoel Grandin
to find any global variable, was checking the wrong property of VarDecl Change-Id: I454b4e0c1701bb0771768a1ee10cd738c4ab0726 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102278 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-01loplugin:externvar is covered by loplugin:externalStephan Bergmann
...so drop the former. But keep the relevant externvar tests by moving them into compilerplugins/clang/test/external.cxx. (Which revealed one difference between the two plugins, regarding certain extern "C" variables in unnamed namespaces, where Clang (and for that matter also e.g. GCC, it appears) deliberately deviates from the Standard and considers them to have external linkage. Add clarifying comments that loplugin:external keeps considering these as having internal linkage, following the Standard.) Change-Id: I344fcd0135fdaf6bf08a4b396af2ed2299389a7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97639 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-26Improve loplugin:elidestringvarStephan Bergmann
...by addressing the follow-up TODO mentioned in the commit message of 7a3736f908c0ae207567603c61ce0f617339bac0 "New loplugin:elidestringvar" (extending it not only to uses with a constant sal_Unicode, but also to uses with OUStringLiteral). (All necessary changes have been made in preceding "Upcoming improved loplugin:elidestringvar" commits.) Change-Id: Ib0000ef9c4a1dad52124dfd039dd936cf7e3ba3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97226 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-10new loplugin:simplifypointertoboolNoel Grandin
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-26new loplugin:xmlimportNoel Grandin
to help me maintain the invariants when updating code to use the FastParser APIs. One weird invariant is that you need to override startFastElement or the createFastChildContext will not get called. Not all of these changes are probably necessary - some of the classes are never constructured themselves, only their subclasses are constructed, and their subclasses maintain the invariants, but it is just easier to scatter a few more startFastElement around Change-Id: I3f70fb5a1e44c311cf4926fa7b0fcda605709eac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89473 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-31new loplugin:namespaceindentationNoel Grandin
check indentation of braces in namespace decls, and the comments that often appear with them. This is my penance for messing up the indentation with clang-tidy-modernize-namespaces. As such I have limited it to new-style namespaces for now, and the check is off by default. Change-Id: I4db7f10a81c79bc0eece8f8e3ee564da8bc7f168 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87723 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-28New loplugin:unsignedcompareStephan Bergmann
"Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-24new loplugin:makesharedNoel Grandin
Change-Id: I4bfcf6e337a6806ab5983a3fa2e2a7b6f2af1c43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-05New loplugin:unusedmemberStephan Bergmann
* See comment at head of compilerplugins/clang/unusedmember.cxx for description. * Moved isAllRelevantCodeDefined from loplugin:fakebool to PluginHandler for reuse. (Made it a member function so that it can reuse its two RecordCompleteMap instances across different loplugins. Probably safer lifecycle-wise to have them as PluginHandler members than to have them as static local variables in function isAllRelevantCodeDefined.) * Need Plugin::ignoreLocation overload for TypeLoc now, thanks to UnusedMember::VisitElaboratedTypeLoc. * UETT_PreferredAlignOf was split off UETT_AlignOf with <https://github.com/ llvm/llvm-project/commit/6822bd79ac43f267613f1615bf60407103e24dba> "PR26547: alignof should return ABI alignment, not preferred alignment". * RecursiveASTVisitor::TraverseAlignedAttr traverses into the attribute's argument only since <https://github.com/llvm/llvm-project/commit/ f26d551387f032e05e5e6551605b150f38c3f5b2> "Do not look through pack expansions when looking for unexpanded parameter packs". Change-Id: Ic2702b03d4567fa2533333766de7920f3c524a69 Reviewed-on: https://gerrit.libreoffice.org/84416 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-26loplugin:implicitboolconversion: Filter out bool -> std::atomic<bool>Stephan Bergmann
...as used since patch set 8 of <https://gerrit.libreoffice.org/#/c/81542/8> "WIP: tdf#120006 New Document converter" Change-Id: I79c2237a2e5839162272c0d49bdb4d87c9e35102 Reviewed-on: https://gerrit.libreoffice.org/83655 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-16sort itemsStephan Bergmann
Change-Id: Ia55b9ce67b22f9cc012ce02208f501580d9f4634 Reviewed-on: https://gerrit.libreoffice.org/82986 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-16Improve loplugin:redundantpreprocessor performance a bitStephan Bergmann
...and add a minimal test for it Change-Id: Ia6c61e41a7e60fd01c639e893c34bd9d215c1513 Reviewed-on: https://gerrit.libreoffice.org/82983 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-14New loplugin:consttoboolStephan Bergmann
...to: "Find implicit conversions from non-'bool' constants (e.g., 'sal_False') to 'bool'". Due to how FALSE is defined as just #define FALSE (0) (i.e., a literal of type 'int') but TRUE is defined as #define TRUE (!FALSE) (i.e., an implicit conversion from 'int' to 'bool') in GLib (see the comment in ConstToBool::VisitImplicitCastExpr), we get more warnings about uses of 'TRUE' than of 'FALSE'. For example, in libreofficekit/source/gtk/lokdocview.cxx there is a warning about the 'TRUE' in g_main_context_iteration(nullptr, TRUE); but not about the 'FALSE' in g_main_context_iteration(nullptr, FALSE); (where the parameter of 'g_main_context_iteration' is of type 'gboolean'). Lets live with that asymmetry for now... (Besides the issues addressed directly in this commit, it also found the two bogus asserts at 7e09d08807b5ba2fd8b9831557752a415bdad562 "Fix useless assert(true) (which would never fire)" and 122a0be8ae480473bd1d7f35e197a2529f4621e3 "Fix useless assert(true) (which would never fire)", plus 5f0d6df7f57ae281fe161e61c7f25d67453fddd2 "Use two-argument form of static_assert".) Change-Id: Id77322de9f94b85a7b65608a03e0e9865d14467b Reviewed-on: https://gerrit.libreoffice.org/82667 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-13Extend loplugin:salbool to loplugin:fakeboolStephan Bergmann
...checking for unnecessary uses of more "fake bool" types. In the past, some of the checks involving the types of variables or data members, or the return types of functions, issued warnings that required surrounding code to be changed too (e.g., when changing the signature of a function whose address was taken). These checks have been tightened now to not warn in such cases (which avoids warnings that require changes to additional code, or changes that might even be impossible to make, at the cost of being less aggressive about removing all unnecessary uses of those "fake bool" types). Change-Id: I70eb75039817cda34ed611387ee27dc5f36a3e2e Reviewed-on: https://gerrit.libreoffice.org/82554 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-12Clarify loplugin:external behavior for const(expr) varsStephan Bergmann
Change-Id: I4a649f9c9ed2015ed9b32a153060df9770b20403 Reviewed-on: https://gerrit.libreoffice.org/82493 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-02New loplugin:conditionalstringStephan Bergmann
Change-Id: I2eab990c15f845b44a3b598571aca361dadf9ff3 Reviewed-on: https://gerrit.libreoffice.org/81946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-15new loplugin:bufferaddNoel Grandin
look for OUStringBuffer append sequences that can be turned into creating an OUString with + operations Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6 Reviewed-on: https://gerrit.libreoffice.org/80809 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-12Enable compilerplugins/clang/test/classmemaccess.cxxStephan Bergmann
...which was added with 8f4fdb405a8470b9d06ab14ced120da89b213e82 "New loplugin:classmemaccess", but I forgot to include this change to solenv/CompilerTest_compilerplugins_clang.mk in that commit Change-Id: If1580b28369443f09dae8882346b1e0ff8214ab4 Reviewed-on: https://gerrit.libreoffice.org/80699 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-02new loplugin:stringaddNoel Grandin
look for places where we can replace sequential additions to OUString/OString with one concatentation (i.e. +) expression, which is more efficient Change-Id: I64d91328bf64828d8328b1cad9e90953c0a75663 Reviewed-on: https://gerrit.libreoffice.org/79406 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-29constmethod for accessor-type methodsNoel Grandin
Apply the constmethod plugin, but only to accessor-type methods, e.g. IsFoo(), GetBar(), etc, where we can be sure of that constifying is a reasonable thing to do. Change-Id: Ibc97f5f359a0992dd1ce2d66f0189f8a0a43d98a Reviewed-on: https://gerrit.libreoffice.org/74269 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-24compiler check for rtl::OUStringConcat instancesLuboš Luňák
Something like auto str = "string" + OUString::number( 10 ); will not be OUString but actually rtl::OUStringConcat (which gets implicitly converted to OUString, but not with auto). Since those refer to temporaries from the expression, they should not outlive the expression. Change-Id: Ib4cde4b38befb3d49927d0cf01c52ebb2d36df89 Reviewed-on: https://gerrit.libreoffice.org/78830 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-19improve and enable loplugin:fragiledestructorNoel Grandin
Where the problem was benign and the class was not extended, I marked the class as final. Where the problem was benign and the class was extended, I marked the relevant callee methods as final. Other cases were excluded in the plugin. Change-Id: Idb762fb2206af4e8b534aa35ff77f8368c7909bc Reviewed-on: https://gerrit.libreoffice.org/79089 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-30new loplugin:noexceptmoveNoel Grandin
idea from mike kaganski look for places where we can mark move operators as noexcept, which makes some STL operations more efficient Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f Reviewed-on: https://gerrit.libreoffice.org/78251 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-08-23new loplugin:returnconstvalNoel Grandin
look for code that thwarts copy-elision/move optimisations by returning const values. Change-Id: Iafa038d15051e06ee76d8a1c0ce8b7d234cd8488 Reviewed-on: https://gerrit.libreoffice.org/77964 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
2019-08-16new loplugin:sequenceloopNoel Grandin
look for places we should be using std::as_const on for-range loops over uno::Sequence, to avoid triggering a copy Change-Id: I7efb641bf09d37c87946f03428ee4eec90298c8a Reviewed-on: https://gerrit.libreoffice.org/77441 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-01new loplugin:mapindexNoel Grandin
Change-Id: I6b5f73b2187009e95d4d666e03e5803f522cee06 Reviewed-on: https://gerrit.libreoffice.org/76584 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-23resurrect and improve loplugin:referencecastingNoel Grandin
Improve the plugin to avoid generating false+ with the special case of querying XInterface (what the code calls normalisation). Also ignore places where the querying is dealing with ambiguous base classes. Change-Id: I23b2b2fa6618328fafc4707b94c26582a462ea87 Reviewed-on: https://gerrit.libreoffice.org/74993 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-13new loplugin logexceptionnicelyNoel Grandin
to be used to find places to use new TOOLS_WARN_EXCEPTION,etc macros Change-Id: I213ab47efa82075435bb800736ee0937aea0486c Reviewed-on: https://gerrit.libreoffice.org/73950 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-24tdf#89522 PERF FILEOPEN xlsx, part 1Noel Grandin
Inherit from tools::WeakBase non-virtually, so that we can use a static_cast in tools::WeakReference::get instead of a dynamic_cast. This takes the file-open time from 1m21 to 40s for me. Add a clang plugin to make sure we don't accidentally end up inheriting from tools::WeakBase more than once. Change-Id: I9c7c36403333f99094e1f9d8cce2ecd9200377f9 Reviewed-on: https://gerrit.libreoffice.org/71231 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-17New loplugin:selfinitStephan Bergmann
...to find more bugs like the one addressed in 6340daac7b99c65249363a4bb61c492de31ef5d6 "Revert broken loplugin:sequentialassign change". What it does is: "Warn when a variable is referenced from its own initializer. This is not invalid in general (see C++17 [basic.life]), but is at least suspicious." It found one false positive (addressed with 884ad0d1af88f9985d30ef0dfe92d89e82f8e576 "Split localProcessFactory function into class with setter and getter") and five true positives (addressed with e0ccbe72ed6eb0d309ed272a78fd67a512acff5d "Fix use of variable before its lifetime begins" and 0e335af4d3f044511551fa2ede20911beaee9b41 "Fix uses of variables before their lifetimes begin"). Change-Id: I4c45cceaa042e93b37ad24a54784c027f6ca1f87 Reviewed-on: https://gerrit.libreoffice.org/70897 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-06-23 08:50:37 +0000