...that had plagued 2e293a731c1559c9869dfcb32491bc600fc18e4e "new
loplugin/rewriter comparisonwithconstant" (in sal/osl/unx/pipe.cxx), and
auto-rewrite the remaining occurrences in sal (that the mentioned commit had
failed to address, for whatever reason)
Change-Id: I3dc3bae8dd92ba8bf576f6e06e7c9ee21f883661
...to avoid -Werror,-Wunused-command-line-argument in case some ASan build
setting passes in such flags
Change-Id: Ia613a10e3564a23715019ee0c7c755cdcbf7a47c
by whitelisting a couple of methods we know only write to their
parameters
Change-Id: Id7aef9c03c23d10c27707b21eb9a0db4a6c2757c
Reviewed-on: https://gerrit.libreoffice.org/37647
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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
* 994e38e336beeacbd983faafac480afc94d3947e "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 839e53b933322b739a7f534af58c63a2c69af7bd
"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
so that instead of trying to maintain a list of false positives inside
the python processing code, I can just run the plugin, generate the
result, and then look at the git diff from last time.
Change-Id: Ic287f19e3b139705222a1f9541ad6471dfcb9c18
look for fields which can be declared inline in the parent class.
start with some likely candidates in svx
Change-Id: I56cdca273272b72bb728ed2e3f5e1e976f8c7c32
Reviewed-on: https://gerrit.libreoffice.org/36262
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
i.e. where the code looks like
{
foo * p = new foo;
...
delete p;
return ...;
}
Change-Id: Id5f2e55d0363fc62c72535a23faeaaf1f0ac6aee
Reviewed-on: https://gerrit.libreoffice.org/36190
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
