| Age | Commit message (Collapse) | Author |
|---|
|
...by re-enabling the code temporarily #if'ed-out in
a528392e71bc70136021be4e3d83732fccbb885e "Fixed/improved
loplugin:cppunitassertequals" (and which then triggers lots of other
lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings).
For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it
was more straightforward to rewrite them with an explicit call to operator ==
(which silences loplugin:cppunitassertequal) than to adapt them to
CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types.
In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been
implemented trivially for now, but might want to combine that with the
DEBUG_PIVOT_TABLE-only ScDPItemData::Dump.
Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which will come in handy for a later improvement of that plugin
Change-Id: I548b9388bee60b381c0a2c820f20f596aa0072f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110453
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
I need that for another upcoming commit.
Change-Id: If7e567c731e454070bf8ad9efb5c2f28ff9049e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93031
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ied9c26248cb72f2146fbe1a985f825f7525fa17c
Reviewed-on: https://gerrit.libreoffice.org/75836
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
idea originally from either tml or moggi, can't remember which
Change-Id: Id78d75035036d3aa1666e33469c6eeb38f9e624d
Reviewed-on: https://gerrit.libreoffice.org/55126
Tested-by: Jenkins <ci@libreoffice.org>
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>
|
|
Change-Id: I26734c13515394162d88351a1cbe2b20abdac865
|
|
* 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
|
|
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 0e1b831b93048c68735f2e2dbdcee587db4862ef
(CppunitTest_vcl_complextext: fix loplugin:cppunitassertequals warnings,
2016-12-16) for an example.
Change-Id: I564fb0724836b6dbbea9262b53ad646e285a339c
|
|
since the latter is rather slow
Change-Id: Ib73cdb923585580777c2265b561c1808e93b2baa
Reviewed-on: https://gerrit.libreoffice.org/33585
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I81e97c5f720535b33dd3ce72d01151765e4e93a0
|
|
Change-Id: I0427c70aa3a7f55aba4bbe0fe571aab08596541a
Reviewed-on: https://gerrit.libreoffice.org/22922
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
look for places we should be calling CPPUNIT_ASSERT_EQUALS instead of
CPPUNIT_ASSERT
Change-Id: Ia836555d569069c6d0dce592f1c9a78bf8d8adb8
|
