...which is there for MSVC compatibility, but can cause getBody() to return null
even when doesThisDeclarationHaveABody() is true.
And in staticmethods.cxx we need to check doesThisDeclarationHaveABody() instead
of hasBody(): For some class template member functions that are only defined
outside their class definition, as is the case for
OSequenceIterator::hasMoreElements in include/comphelper/sequence.hxx, hasBody()
may be true for the original member function declaration inside the class (as
there is some later definition that does have a body), but
isLateTemplateParsed() is not (it is only true for the later definition). So
just skip any such declarations that are not definitions (which is sane anyway,
as otherwise such functions could pointlessly be inspected multiple times).
Change-Id: I724f652a8f060a931f8b5fc3e4feb5f307a922bf
Reviewed-on: https://gerrit.libreoffice.org/42914
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
makes writing nice code awkward sometimes.
Also split plugin into two different plugins, the logic was getting
tangled up.
Change-Id: I232e314d29c766c160c29373988dc37a466505be
cf. d150eab88ee26d5c05a6d662a2c13c6adea8ad78 "loplugin:passstuffbyref: For now
disable 'pass parm by value' warnings". At least all the other changes in
4d49c9601c9b3e26a336e08e057d299895683480 "Let loplugin:passstuffbyref also look
at fn defn not preceded by any decl" were OK but the one reverted with
b3e939971f56d53e60448a954a616ec295544098 "coverity#1362680 Pointer to local
outside scope".
Change-Id: I022125fbcb592e7da3c288c0fd09079dd2e87928
That needs fixing, to check that the parm is not bound to a reference, cf.
<https://gerrit.libreoffice.org/#/c/26189/> "coverity#1362680 Pointer to local
outside scope".
Change-Id: I3656354ccd10affafa006c9e46cf1db608b5b2a7
mostly missing explicit before ctors and
uninitialized member vars
one odd use of std::find
> compilerplugins/clang/implicitboolconversion.cxx
> 800 stlIfFind warning Suspicious condition.
> The result of find() is an iterator, but it is not properly checked.
Change-Id: Iade53494cd7fe8ddb0e110e431449ae5a517fe3b
Reviewed-on: https://gerrit.libreoffice.org/24398
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
of methods like
Foo getFoo() const { return m_foo; }
where we can rather do
const Foo& getFoo() const { return m_foo; }
and let the client code decide if it wants copy Foo.
Inspired by a performance problem where we were unwittingly
copy constructing a large struct repeatedly just so client code
could interrogate the members of the struct.
When all of the changes this plugin finds are applied, I find
that 'perf stat make check' shows on average a 1.7% reduction
in CPU cycles.
Change-Id: Ic27b4f817aa98f2a2a009f2d4e4a962cbe9c613e
This should fix a regression from 3bdd176731c351638f541a37b94094124f3c9f52,
apparently the cppcheck's advice is misleading.
Change-Id: I427ecaa1eb3c9841cb6112997b9b51feda4583d0
Only consider base declarations, not overriden ones, or we warn on methods that
are overriding stuff from external libraries.
Change-Id: I08791c96f7adba5997ad237a98e7c08a759042ad
Detect arguments larger than 64 chars passed by value.
Change-Id: I9b0ea9ccb99d115984a26eab67c9cf6afd5f6cae
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
