Age | Commit message (Collapse) | Author |
|
"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>
|
|
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>
|
|
Change-Id: Id70abc5d1ccdc41dc771fe77ad0e7584efe76826
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132569
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
Change-Id: Ia45119e11377e916a1e1deb5648ed9033c417d77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107228
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
<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>
|
|
Change-Id: I1548a76fdc03afee68f1e5c01bc665e616f2edf2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86501
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
...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>
|
|
Change-Id: I7b9b41a7081281214a387cdf02080866e9b9dfe7
Reviewed-on: https://gerrit.libreoffice.org/68873
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
..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>
|
|
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>
|
|
...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>
|
|
...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>
|
|
...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>
|
|
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>
|
|
<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>
|
|
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>
|
|
(but which finds no new hits)
Change-Id: I862a3c82932ee6d6d0946cd33f965bb8e917cff8
|
|
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
|
|
...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>
|
|
Change-Id: I427b15b35ef6e7c803cb8a00c961d35175ae8cb2
|
|
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>
|
|
"TW_BOOL" seen e.g. in extensions/source/scanner/scanwin.cxx
"boolean" seen e.g. in extensions/source/activex/SOActionsApproval.h
Change-Id: I78281cd4f92c3e0c0d885cc2466665a06f5bcd85
|
|
...to also cover cases like conversion betwen LPVOID and HANDLE in Windows-only
code
Change-Id: I934fe89372ee7a12462e7ad4284b9ea2cc73ce5a
|
|
Change-Id: I4d50b77745d68a23136221ef06f327137e89fa7e
|
|
Change-Id: Ice5fcb8f598b079afde3346f569d9619f1383506
|
|
Change-Id: I7cb43f915565dadd611b90ee30373e472f97efb5
Reviewed-on: https://gerrit.libreoffice.org/26748
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|