...when the target type is a reference type and the source and target type have
different cv qualifiers. (And fix the fallout. And make the tests cover that
somewhat more exhaustively; and while at it also test that the plugin can cope
with dynamic_cast to void pointers, which is the only legitimate case where a
dynamic_cast can involve types that are not (pointers or references to)
non-class types.)
Change-Id: Ia568ddb5dbc4a84c275db172791c345d95964857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143133
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...<bdc6974f92>
"[clang] Implement ElaboratedType sugaring for types written bare".
For one, it caused diagnostics to now emit 'OString' instead of 'rtl::OUString'
etc., which required adapting a number of tests.
For another, some tests started to fail because the relevant plugins didn't
expect ElaboratedType sugar in places where it now occurs:
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/redundantcast.cxx Line 297: redundant cstyle cast from 'Enum1' to 'Enum1' [loplugin:redundantcast]
> File compilerplugins/clang/test/redundantcast.cxx Line 308: redundant cstyle cast from 'Enum1' to 'Enum1' [loplugin:redundantcast]
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/referencecasting.cxx Line 25 (directive at compilerplugins/clang/test/referencecasting.cxx:24): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> File compilerplugins/clang/test/referencecasting.cxx Line 37 (directive at compilerplugins/clang/test/referencecasting.cxx:36): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> File compilerplugins/clang/test/referencecasting.cxx Line 48 (directive at compilerplugins/clang/test/referencecasting.cxx:47): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> File compilerplugins/clang/test/referencecasting.cxx Line 100 (directive at compilerplugins/clang/test/referencecasting.cxx:99): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> File compilerplugins/clang/test/referencecasting.cxx Line 120 (directive at compilerplugins/clang/test/referencecasting.cxx:119): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> File compilerplugins/clang/test/referencecasting.cxx Line 188 (directive at compilerplugins/clang/test/referencecasting.cxx:187): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> File compilerplugins/clang/test/referencecasting.cxx Line 200 (directive at compilerplugins/clang/test/referencecasting.cxx:199): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> File compilerplugins/clang/test/referencecasting.cxx Line 206 (directive at compilerplugins/clang/test/referencecasting.cxx:205): the source reference is already a subtype of the destination reference, just use = [loplugin:referencecasting]
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/typedefparam.cxx Line 42: function param 1 at definition site does not match function param at declaration site, 'FooT *' (aka 'test2::Foo *') vs 'struct Foo *' [loplugin:typedefparam]
> File compilerplugins/clang/test/typedefparam.cxx Line 55: function param 1 at definition site does not match function param at declaration site, 'FooT *' (aka 'test3::Foo *') vs 'Foo *' [loplugin:typedefparam]
> error: 'note' diagnostics seen but not expected:
> File compilerplugins/clang/test/typedefparam.cxx Line 40: declaration site here [loplugin:typedefparam]
> File compilerplugins/clang/test/typedefparam.cxx Line 53: declaration site here [loplugin:typedefparam]
Hopefully, there are not too many places in our plugins left that similarly
don't expect ElaboratedType sugar in certain places, but which are not covered
by tests. At least, a full build didn't turn up any further false positives,
but there may of course be false negatives now that would go undetected.
Change-Id: I9bfb1cfb57df5f6e228b512c19c664d48285b675
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137049
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
With the recent implemenation of
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" in Clang 13 trunk as
<bf20631782>
"[clang] Implement P2266 Simpler implicit move", a --with-latest-c++ build
started to fail with
> In file included from sal/rtl/random.cxx:25:
> include/o3tl/temporary.hxx:21:62: error: non-const lvalue reference to type 'double' cannot bind to a temporary of type 'double'
> template <typename T> constexpr T& temporary(T&& x) { return x; }
> ^
> sal/rtl/random.cxx:97:37: note: in instantiation of function template specialization 'o3tl::temporary<double>' requested here
> return std::modf(random, &o3tl::temporary(double()));
> ^
etc. (And fixing that by adding the recommended static_cast then triggered a
false loplugin:redundantcast warning.)
Change-Id: I222429e9872afdedf77a07014c0a2e9e06c60b50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<https://github.com/llvm/llvm-project/commit/
5689b38c6a4220cc5f6ba68a56486229b10071bf> "Removed a RecursiveASTVisitor feature
to visit operator kinds with different methods".
That change is incompatible in that before the change individual TraverseUnary*
and TraverseBin* functions were called, while now TraverseUnaryOperator and
TraverseBinaryOperator/TraverseCompoundAssignOperator are called for all the
different operators. Fixed that with a few #if for the non-shared plugins, but
that doesn't work for the shared plugin. So made the two affected plugins non-
shared for now and left a better fix as a TODO.
Change-Id: I5b87d329ae2c4c93bf605bb1ecc9641039f014a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
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>
...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>
...that the compiler is free to elide anyway. (See
4e7ffc0a69 "Avoid compiler eliding#redundant
dynamic_cast" and 380d6afe5f "Remove redundant
asserts involving dynamic_cast".)
Change-Id: I3f75154fee3e978b7ba95a5a27589417065599bd
...when t1 is ElaboratedType sugar (which isn't only used when the type is
written with an elaborated type keyword, but also when it is written with a
qualified name).
(I originally wrote testArithmeticTypedefs to track down a different issue,
which turned out to be a non-issue, with this fix as fall-out. So that test
doesn't quite match the theme of this commit, but is a worthwhile addition
nonetheless.)
Change-Id: Ic447da4399853d7d045e3e2e7ade8ddf52d89749
<sberg> noelgrandin, 718cdd43c2 now also
looks through typedef sugar, e.g. complaining about a gdouble -> double
expl. conversion in configmgr/source/dconf.cxx;
I think we want to remain silent about such conversions involving typedefs
<noelgrandin> sberg, ah, good point.
Change-Id: Icbb0d6be273f53e507c91556cf0ccb5a5c03e5a1
Reviewed-on: https://gerrit.libreoffice.org/41175
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
<http://reviews.llvm.org/D22128> "Make CastExpr::getSubExprAsWritten look
through implicit temporary under CK_ConstructorConversion" was biting me again.
(I had originally developed loplugin:stringcopy against a Clang build that
includes my local fix for that issue. I really need to see to get that resolved
upstream...)
(And while 9578741684 "loplugin:stringcopy" was
actually a false positive, it doesn't hurt either, so just keep it.)
Change-Id: I726956adfbe67681005173cfdfed2e4b4cd6253d
