...where prior to r183883 "Implement core issue 903: only integer literals with
value 0 and prvalues of type std::nullptr_t are null pointer constants from
C++11 onwards," Expr::isNullPointerConstant with NPC_NeverValueDependent could
go into an llvm_unreachable case.
Change-Id: I29cf093f18ece4cd83fd759e30f72c2a71f69554
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
Find places where we are returning a pointer to something, where we can
be returning a reference.
e.g.
class A {
struct X x;
public X* getX() { return &x; }
}
which can be:
public X& getX() { return x; }
Change-Id: I796fd23fd36a18aedf6e36bc28f8fab4f518c6c7
Create a rewriting plugin for finding methods that simply return
object fields, and should therefore be declared in the header,
so that the compiler can reduce method calls into a simple
fixed-offset load instruction.
Change-Id: I7a620fc54250b79681918dc31ed9a8f21118c037
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
...which does not make sense. On Linux and Mac OS X, they potentially end up
exported from multiple libs (weakly, though), while on Windows the potentially
even end up not emitted at all, which could cause link errors.
Change-Id: I092c9ba39e686c17b6e91581cdd4753f1c4d582f
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>
Implement a clang plugin to find them, and clean up existing code
to pass them by reference.
Change-Id: If642d87407c73346d9c0164b9fc77c5c3c4354b8
Reviewed-on: https://gerrit.libreoffice.org/9351
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
...which appears to be a good heuristic to identify functions that are either
unused or should better be declared just once in an include file. (It also
filters out SAL_DLLPUBLIC extern "C" function definitions, which are most likely
meant to be referenced dynamically via dlsym.)
Change-Id: I7fb78cb836b971791704851535dcfbda2b2f5bc0
since it only contains a single sal_Bool site now, and we want
to leave that alone since it's a copy of similar stuff in cppuhelper.
Change-Id: I3cf4cf5f67e95d5b6f70371181f77c5451fcbf50
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
It's not very efficient, because we generally end up copying it twice -
once into the parameter and again into the destination OUString.
So I create a clang plugin that finds such places and generates a
warning so that we can convert them to pass-by-reference.
Change-Id: I5341a6ea9e3190f4b4c05c42c85595e3dcd83361
...and subsumes not only the use of __builtin_expect in assert, but also the use
of __builtin_constant_p (nested) in htonl on Mac OS X.
Change-Id: I62ab6c71c42948c4ec1e2f1e1d23223cbb13416b
...that would not lead to silent changes of the code. That is, it does not warn
about sal_Bool parameters of virtual functions, so that (not yet rewritten)
overrides do not silently become overloads instead.
The plugin is in store/ for now, because not all of the code has been cleaned up
yet.
Change-Id: I6e9b3847eb26c3090f375045188d38097052defe
