summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/check.cxx
AgeCommit message (Collapse)Author
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>
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>
2020-03-02Adapt compilerplugins to Clang trunk changeStephan Bergmann
<https://github.com/llvm/llvm-project/commit/ 93184a8eda272c65308906836b47cbf209de779e> "Remove unused parameter from CXXRecordDecl::forallBases [NFC]" Change-Id: I8efdda2a37fd0df3b964401e8851a0f95f8d0ab4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89781 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-09Improve loplugin:redundantcast for sal_Int... vs. ::sal_Int...Stephan Bergmann
Change-Id: I1548a76fdc03afee68f1e5c01bc665e616f2edf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86501 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-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-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>
2018-08-17Avoid loplugin:redundantcast false positive involving decltypeStephan Bergmann
..with libc++ on macOS: > /Users/stephan/Software/lo2/core/sw/source/core/doc/CntntIdxStore.cxx:238:44: error: static_cast from 'decltype(__x.base() - __y.base())' (aka 'long') prvalue to 'long' prvalue is redundant [loplugin:redundantcast] > const MarkEntry aEntry = { static_cast<long>(ppBkmk - pMarkAccess->getAllMarksBegin()), false, pBkmk->GetMarkPos().nContent.GetIndex() }; > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: I94ab3d828482462c0fde26e19c9cc6508efa00fe Reviewed-on: https://gerrit.libreoffice.org/59240 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-13Various loplugin warnings in mysqlStephan Bergmann
I assume the "0 == " around columnStringValue.equalsIgnoreAsciiCase in ODatabaseMetaData::getSchemas (mysqlc/source/mysqlc_databasemetadata.cxx) was just a thinko, as the latter already returns sal_Bool, not a <0 / 0 / >0 integer value. (Rebased atop ce24919c01d1ab77f962137ff04a31dd5ec944af "loplugin, various in mysqlc", which covered the same warnings, but didn't consider the negated call to equalsIgnoreAsciiCase to be an accident as I do here (see above), and accidentally reversed the logic of OResultSetMetaData::isNullable in mysqlc/source/mysqlc_resultsetmetadata.cxx, I think.) Change-Id: Ie89cc8ef7c7638d28307a4b240930d387d75b8f2 Reviewed-on: https://gerrit.libreoffice.org/58908 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-06-29Improved loplugin:redundantcast (const-qualified typedefs)Stephan Bergmann
...see comments to <https://gerrit.libreoffice.org/#/c/56661/> "This cast seems completely unnecessary to me?" Change-Id: I57d27cd2aa2dc94bc2e0b49fe06a09d31301cb7e Reviewed-on: https://gerrit.libreoffice.org/56708 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-03-23Check isOkToRemoveArithmeticCast in loplugin:redundantfcast tooStephan Bergmann
...to avoid warnings like > C:/lo64/core/svx/source/table/accessiblecell.cxx(400,12): error: redundant functional cast from 'long' to 'sal_Int32' (aka 'long') [loplugin:redundantfcast] > return sal_Int32(0x0ffffffL); > ^~~~~~~~~~~~~~~~~~~~~ with clang-cl Change-Id: I4a48a9f10ad75f76a3c6ab6152ab279df9a3fbcc Reviewed-on: https://gerrit.libreoffice.org/51780 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-23Remove unused TypeCheck::SubstTemplateTypeParmTypeStephan Bergmann
...introduced unused with 91b4e4531621b7afb2dbab1a8aa62c92da66951a "new loplugin: pointerbool" Change-Id: I3af0ce878f1f2742223d66bcdade4e9c144162cd Reviewed-on: https://gerrit.libreoffice.org/48387 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-23new loplugin: pointerboolNoel Grandin
look for possibly bogus implicit conversions to bool when passing (normally pointer) args to bool params. this plugin comes in the wake of a couple of bugs caused by refactoring, where some of the call sites were not currently updated. Of the changes, the following are real bugs: desktop/../dp_persmap.cxx StartInputFieldDlg in sw/../fldmgr.cxx which occurred as a result of commit 39d719a80d8c87856c84e3ecd569d45fa6f8a30e Date: Tue May 3 11:39:37 2016 +0200 tdf#99529 sw: don't pop up input field dialog before inserting field CSerializationURLEncoded::encode_and_append in forms/../serialization_urlencoded.cxx XclExpCFImpl::XclExpCFImpl in sc/../xecontent.cxx I have no idea how to properly fix this, just made a guess. SwDocTest::test64kPageDescs in sw/qa/core/uwriter.cxx which looks like a simple copy/paste error. Change-Id: I795ebd5ef485a1d36863dc27fe13832989f5a441 Reviewed-on: https://gerrit.libreoffice.org/48291 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-12-19Bump --enable-compiler-plugins to Clang 3.8.0Stephan Bergmann
<https://lists.freedesktop.org/archives/libreoffice/2017-December/079107.html> "Clang baseline bump" Change-Id: I18fca8794ea34118fc6308458064d0c28cf5caf7 Reviewed-on: https://gerrit.libreoffice.org/46557 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-09loplugin:unusedvariable add some more std:: typesNoel Grandin
Change-Id: Ib15931e415990b56367fe3e1c7cf3f22cc4826d5 Reviewed-on: https://gerrit.libreoffice.org/44529 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-08Fix loplugin::unusedvariablecheck check for std classesStephan Bergmann
(but which finds no new hits) Change-Id: I862a3c82932ee6d6d0946cd33f965bb8e917cff8
2017-11-08Remove obsolete "lo_warn_unused" workaroundStephan Bergmann
Per README.md, Clang 3.4 is the baseline for --enable-compiler-plugins, which is the sole consumer of the "lo_warn_unused" attribute, but Clang 3.4 already supports HAVE_GCC_ATTRIBUTE_WARN_UNUSED. Change-Id: I9654028e24852335e463c73bcb5ece5e5b54d53c
2017-07-14loplugin:oncevar: empty stringsStephan Bergmann
...which showed that checking the parent statement (which may be too large to) in OnceVar::VisitDeclRefExpr is inadequate. Change-Id: I07fb8ba9e2dfbd0c65a2723737d14abcddcefec4 Reviewed-on: https://gerrit.libreoffice.org/39757 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-07-03loplugin:casttovoidStephan Bergmann
Change-Id: I427b15b35ef6e7c803cb8a00c961d35175ae8cb2
2017-03-22loplugin:redundantcast find redundant c-style enum castsNoel Grandin
Change-Id: I2dab376d87804521aed6b6bd41ad7762830fa349 Reviewed-on: https://gerrit.libreoffice.org/35467 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-22Some more bool-like types for Windows/clang-clStephan Bergmann
"TW_BOOL" seen e.g. in extensions/source/scanner/scanwin.cxx "boolean" seen e.g. in extensions/source/activex/SOActionsApproval.h Change-Id: I78281cd4f92c3e0c0d885cc2466665a06f5bcd85
2016-12-18Generalize typedef-to-void* check in loplugin:redundantcastStephan Bergmann
...to also cover cases like conversion betwen LPVOID and HANDLE in Windows-only code Change-Id: I934fe89372ee7a12462e7ad4284b9ea2cc73ce5a
2016-07-08loplugin:redundantcast: redundant static_castsStephan Bergmann
Change-Id: I4d50b77745d68a23136221ef06f327137e89fa7e
2016-06-29Further clean-upStephan Bergmann
Change-Id: Ice5fcb8f598b079afde3346f569d9619f1383506
2016-06-28More Clang 3.4 "(anonymous namespace)" fixesStephan Bergmann
Change-Id: I7cb43f915565dadd611b90ee30373e472f97efb5 Reviewed-on: https://gerrit.libreoffice.org/26748 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>