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>
...of <http://llvm.org/viewvc/llvm-project?view=revision&revision=331155>
"PR37189 Fix incorrect end source location and spelling for a split '>>' token",
changing (among others) the return type of getImmediateExpansionRange from a
std::pair of token locations to CharSourceRange (which will typically also
represent token locations, but might also represent char locations).
For now, map the return value of getImmediateExpansionRange back to a std::pair
(as expected by our compilerplugins code in its current form), and mark the
char location case with a TODO (which will need to be addressed if any of our
plugins starts to produce wrong results due to not handling that char location
case). In the long run, we should instead adapt our code to use the new return
type of getImmediateExpansionRange directly.
Change-Id: Idc2f5dc43830af4798b55bf605976c4ab146c522
Reviewed-on: https://gerrit.libreoffice.org/53817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* 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
This forces writing a comparision of two variables in the
CPPUNIT_ASSERT_EQUALS(expected, actual) form, rather than
CPPUNIT_ASSERT(actual == expected). The benefit is when the test fail,
it's more clear what are these two values, rather than just seeing that
they are not equal.
In the relatively rare case when the types are not streamable, the
plugin can be silenced using CPPUNIT_ASSERT(bool(it == foo.end())). But
please always first consider making the type streamable instead. See
commit 0e1b831b93
(CppunitTest_vcl_complextext: fix loplugin:cppunitassertequals warnings,
2016-12-16) for an example.
Change-Id: I564fb0724836b6dbbea9262b53ad646e285a339c
