to find ref-counted classes being managed via other smart pointer
classes.
Hopefully prevent needing fixes like
642ae256ea
"ChangedUIEventListener is refcounted, mustn't be helt by unique_ptr"
Change-Id: I6b0c5f8f87ce3546a8a1104ce1000470c09459bd
Reviewed-on: https://gerrit.libreoffice.org/39378
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
we look for any kind of scalar variable now that deserves to be inlined,
and we check for variables that cannot be inlined because they are being
passed by reference, or modified, or have their address taken
Change-Id: Ia744a180e91d1516140a1555d4514f6fa4de1c0b
Reviewed-on: https://gerrit.libreoffice.org/38966
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
When the field in question is read from inside a constructor
initializer.
In the process, create some needed infrastructure in the plugin classes.
Change-Id: I2f440efa6912801a236727c9fe3180404616958c
Reviewed-on: https://gerrit.libreoffice.org/38960
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
tell the plugin code when we are unit-testing it, so we can suppress all
the warnings except for the plugin we are currently testing
Change-Id: I240c8e37eba90c219e53c29531a3a43bc841a1c8
(such redundant std::unique_ptr copies could happen when changing parts of the
code base to make use of std::unique_ptr individually)
Change-Id: Ib48a45a212f9426a775c7f379bc5d3c92230218a
For the c-char in the u'...' literal, the preceding commits consistently use:
* a simple-escape-sequence if the original code already used one
* \0 for U+0000
* the (\ escaped, for ' and \) source character matching U+0020..7E (even if it
is not a basic source character)
* a consistently four-digit hexadecimal-escape-sequence otherwise, \xNNNN
For non-surrogate code points, the last case could probably also use \uNNNN
universal-character-names. However, for one, it isn't quite clear to me whether
conversion of such to members of the execution chacacter set in character
literals (in translation phase 5) is implementation-specific. And for another,
the current C++ standard references the dated (no pun intended) ISO/IEC
10646-1:1993 specification, rather than the current ISO/IEC 10646:2014, and
requires that a universal-characrer-name designate a character with a specific
"character short name in ISO/IEC 10646", but I do not find a specification of a
"short name" in ISO/IEC 10646:2014 and don't have access to ISO/IEC
10646-1:1993, so am not sure whether that would e.g. cover noncharacters like
U+FFFF.
(The only exception is one occurrence of u'\x6C' in bestFitOpenSymbolToMSFont,
filter/source/msfilter/util.cxx, where it is clear from the context that the
value denotes neither a Unicode code point nor a UTF-16 code unit, but rather an
index into the Wingdings font glyph table.)
Change-Id: If36b94168428ba1e05977c370aceaa7e90131e90
* 994e38e336 "loplugin: use TypeCheck instead of
getQualifiedNameAsString" had effectively disabled this plugin (Asserter is a
struct, not a namespace). Fixed that.
* Also improved the checks, for one removing the---expensive---use of
Plugin::parentStmt, for another making the plugin look into (...), !..., and
...&&... expressions.
* However, as the plugin had effectively already been disabled (see above) when
it was switched on generally with 839e53b933
"compilerplugins: enable loplugin:cppunitassertequals by default", it now hit
way more places than I had initially anticipated. To keep the amount of work
manageable, midway-through I disabled looking into ...&&... expressions for
now. That will be enabled (and resulting warnings fixed) in follow-up
commits.
* Checks like
CPPUNIT_ASSERT(a == b)
that actually want to check a specific overloaded operator == implementation,
rather than using such an operator == to actually check that a and b are
equal, can be rewritten as
CPPUNIT_ASSERT(operator ==(a, b))
to avoid false warnings from this plugin.
Change-Id: If3501020e2d150ad0f2454a65a39081e31470c0f
...where the "controlling expression" of any sort of loop contains a sub-
expression of the form
var < val
where the type of var is smaller than that of val. Theoretically, this could
turn up lots of false positives, but practically it didn't run into any. Most
findings have been cleaned up over the last weeks. There's just a handful
remaining places that are hard to clean up, so I flagged them here with
(deliberately awkward) sal::static_int_cast for later clean-up.
Change-Id: I0f735d46dda15b9b336150095df65cf247e9d6d3
Reviewed-on: https://gerrit.libreoffice.org/35682
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For some reason, e.g. Clang 3.8.1 doesn't evaluate std::strlen here (though it
apparently does in other places in this file).
Change-Id: Ib2b7dcc1d7b6ae47ef285bd2edb65e399dc11b79
Reviewed-on: https://gerrit.libreoffice.org/33547
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
