Detect arguments larger than 64 chars passed by value.
Change-Id: I9b0ea9ccb99d115984a26eab67c9cf6afd5f6cae
Signed-off-by: Stephan Bergmann <sbergman@redhat.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
...to be able to find problems like 6e0bdf04add338b7d5b29fc7b3fc9f08cfd5e96f
"sal_Bool arg of SetUseImagesInMenus was abused to squeeze '2' through it"
earlier when converting occurrences of sal_Bool to bool.
Restricting this check to function call arguments avoids too much noise while
hopefully still catching all the relevant problems.
(This check partially overlaps the pointertobool check, so implicit conversions
from pointers to bool call arguments will now generate two loplugin warnings,
but that's harmless.)
Change-Id: I0b03b1d1615aaf8bc18e7a84c56fff3ef9903508
...as found in Mac OS X' assert macro definition,
__builtin_expect(!(e), 0) ? ... : ...
with type
long __builtin_expect(long, long)
The code in literaltoboolconversion.cxx is needed for
assert(false);
Change-Id: I42f87482c56986af74b2ec849db9852f74c7c938
...that easily works around the problem that in a rewriter rewriting types of
VarDecls like
T x, y;
it would try to replace T twice. Also, keep the list of removals globally with
the (global) rewriter.
Change-Id: I55b8d11986c2a29e09ff40132fd114a0cc48dc90
First, I updated the clang rewriter to do the conversion.
Then I lightly hand-tweaked the output for the few places where
the rewriter messed up, mostly when dealing with calls on "this".
Change-Id: I40a6a977959cd97415c678eafc8507de8aa3b1a9
Reviewed-on: https://gerrit.libreoffice.org/7879
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
