And while at it remove the unneeded getPlatformGlyphCache
abstraction.
Change-Id: Id5cad751eda9e6bf177dfb4816280d7c5af7066a
Reviewed-on: https://gerrit.libreoffice.org/83125
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Errors were:
/home/chris/repos/libreoffice-latest/compilerplugins/clang/sharedvisitor/analyzer.cxx:80:40: error: reference to 'PointerType' is ambiguous
if (auto const t = type->getAs<PointerType>())
/home/chris/repos/libreoffice-latest/compilerplugins/clang/external.cxx:61:44: error: reference to 'PointerType' is ambiguous
else if (auto const t3 = t1->getAs<PointerType>())
Change-Id: Ia5b7add8f2b3160fa3198ed127785bdd61c74796
Reviewed-on: https://gerrit.libreoffice.org/83030
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...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>
...ignoring uses of "BOOL" in Objective C for now
Change-Id: I3eb48dc8d2592285f03f75dc7bc1b21e2383644d
Reviewed-on: https://gerrit.libreoffice.org/82803
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...into an unnamed namespace. (And make it into a "leading comment" that
precedes the code it appeartains to. It had orignally been meant as a "trailing
comment" that follows the code it appeartains to, and had been idented further
to indicate that, but clang-format unhelpfully breaks such indentation of
trailing comments that need to be preceded by a line break due to line length
limitations.)
Change-Id: I6a71a6b8e11ba641acfb542142fe14b4b6445f51
Reviewed-on: https://gerrit.libreoffice.org/82792
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...not just those that came before
Change-Id: Ib10ca34cb2ee63124999d56bb00d94f000f33ea1
Reviewed-on: https://gerrit.libreoffice.org/82782
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which internally uses __builtin_expect and thus caused
> core/include/com/sun/star/uno/Any.hxx:750:13: error: implicit conversion of constant 1 of type 'long' to 'bool'; use 'true' instead [loplugin:consttobool]
> assert(false); // this cannot happen
> ^~~~~~~~~~~~~
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/assert.h:93:6: note: expanded from macro 'assert'
> (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e) : (void)0)
> ^~~~~~~~~~~~~~~~~~~~~~~~~
(See 216bcceee1ba908f617deb3f2404aff8085d5358 "Special handling of
__builtin_expect in boolean expressions" for a similar fix in
loplugin:literaltoboolconversion.)
Change-Id: I4cf4b21006176c908995f5753dd0a38165383d87
Reviewed-on: https://gerrit.libreoffice.org/82773
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and improve diagnostics a bit
Change-Id: I3233aa1752620ddbe6fbeff93b15565921f0bc2e
Reviewed-on: https://gerrit.libreoffice.org/82767
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...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>
(When temporarily taking a plugin out of the shared plugin by modifying its
leading
> #ifndef LO_CLANG_SHARED_PLUGINS
line I often forget about a trailing
> #endif // LO_CLANG_SHARED_PLUGINS
line, which then caused a hard to understand
> [GEN] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx
> Incorrect version ''
failure. This way, at least somehow mention the name of the problematic plugin
to give a bit of a clue.)
Change-Id: I9a9178ba0d7a32f448e91076376989f088ea70f8
Reviewed-on: https://gerrit.libreoffice.org/82657
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...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>
(I'm planning to use it for a FilteringRewritePlugin.)
And while at it, base its current uses on FilteringPlugin.
Change-Id: I0acdcc6cb0b3a434b425405c8c438dbf65e4d3cb
Reviewed-on: https://gerrit.libreoffice.org/82451
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so I don't read the "then" block as being a sequential statements
Change-Id: Ib2004acd3518bd4ebd2246f02a26c2c0a8bbab4c
Reviewed-on: https://gerrit.libreoffice.org/82069
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
See comments at <https://gerrit.libreoffice.org/#/c/81958/> "Only initialize
function pointer once" for a case where such a false warning caused trouble (in
a lambda with deduced return type and multiple return statements).
Change-Id: I64b0b8c45bd3d2a6075e336c361ec778fa0da481
Reviewed-on: https://gerrit.libreoffice.org/82034
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to find StringLiteral on the RHS of +=. Which revealed that the
VisitCompoundStmt/checkForCompoundAssign logic needed to be fixed, too, so that
s += side_effect();
s += "literal";
s += side_effect();
only gets combined to
s += side_effect() + "literal";
s += side_effect();
and not all the way to
s += side_effect() + "literal" + side_effect();
Change-Id: I432e3458b933a7d0ad6141c747b675cc8b0f0ba4
Reviewed-on: https://gerrit.libreoffice.org/81804
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which had been broken since dfc0dc4801707b2d8080af1540625b43bd463e17
"loplugin:casttovoid: fix containsPreprocessingConditionalInclusion()", and,
when range.getEnd() was a macro loc, would typically have wandered off past
the end of the intended range, until it would have encountered some #if etc.
and erroneously returned true. Fixed the fallout across the code base.
While at it, added a clarifying comment and made the "lexing fails" cases that
should never happen fail with a fatal error in debug mode.
Change-Id: Ieff44548384426d7716b6fc6c836c9069d878729
Reviewed-on: https://gerrit.libreoffice.org/81721
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
need to check after we generate the inherited-from set, not before
Change-Id: Ic66deeb680f4a2505d66f99872ac7a5bc263cda9
Reviewed-on: https://gerrit.libreoffice.org/81636
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
where making them final gives the compiler freedom to de-virtualise some
calls
Change-Id: I5755a41c42d9f23af58b873efae37a1d240fbd89
Reviewed-on: https://gerrit.libreoffice.org/81618
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
if one side of the expression is a compile-time-constant, we don't need
to worry about side-effects on the other side
Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b
Reviewed-on: https://gerrit.libreoffice.org/81589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...similar to OUStringChar, to be used in string concatenation expressions. And
enable the corresponding loplugin:stringadd check, and fix its findings.
Change-Id: I35ebb2253ba82bda6c98ae6ebd2ad4f27cf9abf9
Reviewed-on: https://gerrit.libreoffice.org/81456
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
it caused clang-cl to crash when processing desktop/source/app/opencl.cxx
Change-Id: I0a39697e75242cd00f12b60477d51a1e5bf96a4f
Reviewed-on: https://gerrit.libreoffice.org/81409
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which fails at least with clang-8.0.0-3.fc30.x86_64 with "clang-8:
/usr/include/clang/AST/Decl.h:277: llvm::StringRef clang::NamedDecl::getName()
const: Assertion `Name.isIdentifier() && "Name is not a simple identifier"'
failed."
Change-Id: I6999240e2b518b6818a43d1e5ac92224300b343f
Reviewed-on: https://gerrit.libreoffice.org/81415
Tested-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which is reported now by Clang 10 trunk with -std=c++2a:
> cui/source/tabpages/tpline.cxx:481:80: error: use of overloaded operator '==' is ambiguous (with operand types 'const XLineEndItem' and 'XLineStartItem')
> if( pItem && ( !pOld || !( *static_cast<const XLineEndItem*>(pOld) == *pItem ) ) )
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~
> include/svx/xlnstit.hxx:43:29: note: candidate function (with reversed parameter order)
> virtual bool operator==(const SfxPoolItem& rItem) const override;
> ^
> include/svx/xlnedit.hxx:43:29: note: candidate function
> virtual bool operator==(const SfxPoolItem& rItem) const override;
> ^
But the base SfxPoolItem::operator == is virtual anyway, so no need to cast
pOld to a derived type.
And once the expression is changed to
!( *pOld == *pItem )
loplugin:simplifybool would kick in, but only with old compilers. So update
loplugin:simplifybool to also kick in on that with latest Clang trunk with
-std=c++2a, and simplify the expression accordingly.
Change-Id: I3de9175b30d8645ed7a52f87cfac320144576cc8
Reviewed-on: https://gerrit.libreoffice.org/81203
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
