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>
...which first added alternative names to and then deprecated getLocBegin/End
Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2
Reviewed-on: https://gerrit.libreoffice.org/58820
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
After f82dc45bdb "Use the canonical TemplateDecl",
builds on macOS (at least those using C++17 and recent trunk libc++) started to
emit false warnings for that
std::pair< Reference<XConnection>,sal_Bool> aRet;
aRet.second = false;
code in dbaccess/source/ui/dlg/DbAdminImpl.cxx. There's a declaration of
std::pair in type_traits and a definition in utility, and for some reason the
declaration in type_traits was deemed the canonical one, while the
SubstTemplateTypeParmType pointed at the definition in utility. So just check
both, the original and the canonical TemplateDecl.
Change-Id: I2fb9d5172c031e6ad4989b215f19d11a4b17f743
Reviewed-on: https://gerrit.libreoffice.org/46474
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in case there are multiple, as is the case at least with recent (towards
GCC 8) libstdc++, where std::pair is forward-declared also in
include/c++/8.0.0/bits/stl_iterator.h, so that in
dbaccess/source/ui/dlg/DbAdminImpl.cxx
std::pair< Reference<XConnection>,sal_Bool> aRet;
aRet.second = false;
failed to reconstruct the sal_Bool template argument and issued a
loplugin:implicitboolconversion warning.
Change-Id: I0054f2596d3f8837b857f1dca2f25952828b12cc
Reviewed-on: https://gerrit.libreoffice.org/45254
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...see a2d814ac1d
"loplugin:implicitboolconversion" and 24eeb4d286
"loplugin:implicitboolconversion" for things previously only found in C++17. As
expected, no further occurrences were found.
Change-Id: Id0ab621b82dc3c40c8b5801413fceb73ade1408a
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 6e0bdf04ad
"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
