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>
needed adapting loplugin:implicitboolconversion to not warn about
Sequence<sal_Bool> arBool({true, false, true});
Change-Id: I971918aab7c958ef8f1e4e0548a84314e95f8325
...(but not Objective-C++ code) where BOOL (aka unsigned char) expressions are
routinely implicitly converted to int per the C rules, e.g., as operands of &&.
Change-Id: I17e5dae9f065aaa814850196b1ef31f8fb07c99b
...so that
... ? isdigit(...) : true
will not trigger a warning (where isdigit is the standard C function returning
int). (Odd code like that will fall out of the improved
loplugin:literaltoboolconversion rewriter shortly.)
Change-Id: If51402bd5f4b3f8b0630e874988f4b836ae246f8
...while avoiding warnings about conversions to bool-like typedefs (sal_Bool
etc.), also in cases where those typedefs are used as type arguments of
template specializations (which is no little feat, and the current code is only
an approximation of it, one that appears to cover the relevant cases in our code
base though).
Change-Id: I0ed3801aec7787bf38b429b66e25244ec00cac9b
...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
...which can act as either a rewriter or a non-rewriter that emits warnings.
Also added COMPILER_PLUGIN_WARNINGS_ONLY=X to demote warnings from plugin X from
errors to warnings, even under --enable-werror.
Change-Id: I05361936240a890515c6bba2459565417c1746b7
...as MSVC would warn about those anyway (at least about cases that do not
compare against literal sal_True/sal_False, but warning even about those helped
clean up lots of redundant
if (foo == true)
instead of just
if (foo)
etc. across the code base).
Change-Id: Iad4b335c35c5411070f04f87f974db7942c288d4
...as they are often enough errors, like a typo in brace placement in
if (foo == (FOO || bar == BAR) && baz)
or a literal true passed as an argument to a function that rather expects an
integer bit mask, etc. The plugin is smart enough to detect interaction with
logically boolean return/parameter types of C functions that use [unsigned] int
instead, and knows the relevant boolean typedefs (sal_Bool, gboolean, etc.).
Change-Id: I5f0e4344fe86589bec35a71018c7effdedf85e3e
