so revert some of the changes from
commit 7a1c21e53fc4733a4bb52282ce0098fcc085ab0e
loplugin:simplifybool for negation of comparison operator
Change-Id: I937d575b86c1e418805d399b0dc16ae91876b4fe
Reviewed-on: https://gerrit.libreoffice.org/45130
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...so that 640e03da110d76b2c7d5ed5b8b8ba3b4367865ba "loplugin:simplifybool re-
activate the !! warning", which did not warn about
!!( nAttribs & ucb::ContentInfoAttribute::KIND_FOLDER )
in ucb/source/core/ucbcmds.cxx (involving sal_Int32 and sal_Int16), would not
have warned about
!!(nMode & nUpdateMode)
in sfx2/source/appl/workwin.cxx (ivolving o3tl::typed_flags<SfxVisibilityFlags>)
either.
Change-Id: Ibe955592951a04b1bd9a9b4e8cc502024bc1d460
Reviewed-on: https://gerrit.libreoffice.org/45083
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...similar to how <https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning
about !! in loplugin:simplifybool consistent" does for loplugin:simplifybool
Change-Id: I23eef400af71c582d380c9bae6546ce06e8a1e18
Reviewed-on: https://gerrit.libreoffice.org/45122
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which had been left out because "lots of our code uses this style, which I'm
loathe to bulk-fix as yet", but now in
<https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have
caused an otherwise innocent-looking code change to trigger a
loplugin:unnecessaryparen warning for
pFormat = (pGrfObj)
? ...
(barring a change to ignoreAllImplicit in
compilerplugins/clang/unnecessaryparen.cxx similar to that in
<https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in
loplugin:simplifybool consistent", which should also have caused the warning to
disappear for the modified code, IIUC).
Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2
Reviewed-on: https://gerrit.libreoffice.org/45088
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
the rewriter is capable of flattening the function
by returning early, and inverting simple conditions. More
complex conditions are just wrapped in "!(x)"
Change-Id: I028fd7b018dc7347c1b323b2a73ab99c18508faa
Reviewed-on: https://gerrit.libreoffice.org/45071
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in the type at the start of a ParmVarDecl, so that it does not erroneously
assume in isSharedCAndCppCode that the whole decl is in "the body of a macro
definition". (Even better might be to check the whole ParmVarDecl is inside one
macro body.)
Turns out that vcl/unx/gtk/gtkdata.cxx indirectly includes stdbool.h via some
vcl/inc/unx/saldisp.hxx -> workdir/UnpackedTarball/epoxy/include/epoxy/glx.h ->
workdir/UnpackedTarball/epoxy/include/epoxy/gl.h, and Clang's stdbool.h contains
> /* Don't define bool, true, and false in C++, except as a GNU extension. */
> #ifndef __cplusplus
> #define bool _Bool
> #define true 1
> #define false 0
> #elif defined(__GNUC__) && !defined(__STRICT_ANSI__)
> /* Define _Bool, bool, false, true as a GNU extension. */
> #define _Bool bool
> #define bool bool
> #define false false
> #define true true
> #endif
since <http://llvm.org/viewvc/llvm-project?view=revision&revision=115028>
"Define _Bool, bool, true, and false macros in <stdbool.h> when we're in a
GNU-compatible C++ dialect. Fixes <rdar://problem/8477819>" while GCC's
stdbool.h has meanwhile been improved with
<https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=216679> "C++11
explicitly forbids macros for bool, true and false" to
> #ifndef __cplusplus
>
> #define bool _Bool
> #define true 1
> #define false 0
>
> #else /* __cplusplus */
>
> /* Supporting _Bool in C++ is a GCC extension. */
> #define _Bool bool
>
> #if __cplusplus < 201103L
> /* Defining these macros in C++98 is a GCC extension. */
> #define bool bool
> #define false false
> #define true true
> #endif
>
> #endif /* __cplusplus */
Change-Id: I42caab83ac6e4d5e5297376136a6bbe6f3d70818
...by structurally comparing complex constexpr exprs that use template functions
that happen to not have been instantiated, so Expr::EvaluateAsRValue et al would
fail. (Which happened with SFX_PRINTER_ALL in SfxViewShell::SetPrinter,
include/sfx2/viewsh.hxx.)
Now all of the LO code base should compile without causing
checkIdenticalDefaultArguments to return Maybe.
Change-Id: I2b103418c2c68f6d2242535c9cca3222a2508778
Reviewed-on: https://gerrit.libreoffice.org/44773
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...introduced with cab6e6836973a9ddfc5ed9df757e07138328c1c3 "Make
checkIdenticalDefaultArguments more precise", causing older Clang to hang when
compiling specific LO source files.
Change-Id: I99cfcad2f0cd9adccd5aa84d21502f586762217f
...when creating objects of the same derived type
Change-Id: I109b614473a2fb5b08dddd07a4fbe757086141a1
Reviewed-on: https://gerrit.libreoffice.org/44716
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
the description in the comment was right, but the code was not
Change-Id: I7c038e7453f4387d33ec6423c0c55446d6d0df47
Reviewed-on: https://gerrit.libreoffice.org/44680
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...instead of blacklisting such cases. Reuses the
checkIdenticalDefaultArguments code that was originally in
loplugin:overrideparam (and appears to work reasonably well for the default
arguments that actually happen in practice).
Change-Id: I9cf2db17101beb135b2039a9b7ed335bd2af2c08
Reviewed-on: https://gerrit.libreoffice.org/44594
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...a using declaration should fix it just fine
Change-Id: I05cf76672bcceb7a94afa602e215a0b5a32de82b
Reviewed-on: https://gerrit.libreoffice.org/44591
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...a using declaration should fix it just fine
Change-Id: I0279994c155775e9a58e93aef8da4522d4fd93fd
Reviewed-on: https://gerrit.libreoffice.org/44590
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for classes containing protected methods where we can convert them
all to private
Change-Id: I4a448341943e0a613cde30501c4012da61dba713
Reviewed-on: https://gerrit.libreoffice.org/44588
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
This now hides one of the ScVbaFormatCondition_BASE::Operator overloads, but
that doesn't get called directly at ScVbaFormatCondition anyway. (And if it
were, we could add an appropriate using declaration to ScVbaFormatCondition.)
Change-Id: I8440b76a5745c6874f7a3bfcbb4bc4ce5618a4c4
For one, loplugin:unusedvariablecheck does not merely check for unused variables
with types from the standard library since
fe2164949b38a7f73883dbdcb3271b94e5c81744 "teach unusedvariablecheck plugin about
SfxPoolItem subclasses", so disabling loplugin:unusedvariablecheck based on
HAVE_GCC_ATTRIBUTE_WARN_UNUSED_STL is wrong.
For another, I have seen no standard library implementation that decorates its
types with such "warn-if-unused" attributes, and
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0600r0.pdf>
"[[nodiscard]] in the Library" (which proposes to add the corresponding C++17
attribute to just a few select functions and no types at all) makes it appear
unlikely that will happen.
Change-Id: I0a7759e1caf3e3137057c9689080948a4d6747e0
(but which finds no new hits)
Change-Id: I5d5f351402797b662a08ec8dca301bd174e22a50
Reviewed-on: https://gerrit.libreoffice.org/44433
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Per README.md, Clang 3.4 is the baseline for --enable-compiler-plugins, which is
the sole consumer of the "lo_warn_unused" attribute, but Clang 3.4 already
supports HAVE_GCC_ATTRIBUTE_WARN_UNUSED.
Change-Id: I9654028e24852335e463c73bcb5ece5e5b54d53c
...when a class derives from multiple (non-virtual) instances of one base class,
and the override disambiguates which of those instances' member to call.
That was the case with SwXTextDocument::queryAdapter
(sw/source/uibase/uno/unotxdoc.cxx), where SwXTextDocument derives from
cppu::OWeakObject through both SwXTextDocumentBaseClass and SfxBaseModel, but
calling queryAdapter through a pointer to SwXTextDocumentBaseClass apparently
needs to call OWeakObject::queryAdapter on the second, SfxBaseModel-inherited
OWeakObject base instance, or else CppunitTest_sw_macros_test fails.
Who knows what other instances of similar non-unnecessary overrides have been
removed with the help of broken loplugin:unnecessaryoverride, for which there
were no tests that started to fail...
Turns out .clang-format lacked "ReflowComments: false" to not break the special
"// expected-error {{...}}" etc. comments in compilerplugins/clang/test/.
Also, use a better location to report loplugin:unnecessaryoverride, to keep
clang-format and loplugin:unnecessaryoverride from fighting over how to split
lines and where to put the comment in
compilerplugins/clang/test/unnecessaryoverride.cxx.
Change-Id: I3b24df24369db12f8ec1080d6c9f7b70ff561a16
Reviewed-on: https://gerrit.libreoffice.org/44418
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that should have been removed in 2446d2b2fb8b091eaae015fd5bb26bd8e0f596f7
"Avoid expensive calls to containsPreprocessingConditionalInclusion"
Change-Id: I2ffe0ec7b6f1ec0b418979f2864bd5de79ab2c9a
...which, according to callgrind, reduces instruction fetch count spent on
compiling sw/source/core/layout/paintfrm.cxx (randomly selected because it is
rather large) by 5% from 41,992,064,226 to 39,861,989,855 (function main() in
clang-6.0).
This is best done by forwarding ignoreLocation calls from Plugin to the
PluginHandler signleton, but due to the tight mutual coupling between plugin.hxx
and pluginhandler.hxx that unfortunately required some reorganization (and two
outstanding TODO clean-ups of temporarily introduced using declarations in
plugin.hxx).
Change-Id: Ia4270517d194def7db7ed80cb6894e9c473e9499
lots of little fixes to make the logic less pessimistic
Change-Id: If368822984250b11b98c56f5890177a1402e8660
Reviewed-on: https://gerrit.libreoffice.org/44168
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...at least in com_GCC_class.mk (com_MSC_class.mk will be addressed in a follow-
up commit), after the recent loplugin:includeform clean-up.
Two static libraries built from external sources needed adjustment, two
compilerplugin tests needed adjustment (which wasn't found by
loplugin:includeform, by design), and one more adjustment in
sal/textenc/generate/.
Change-Id: Idad5ae355a02ae130369a9a45b5f5925ab48ffef
Reviewed-on: https://gerrit.libreoffice.org/44174
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
parked in store/ for now, because, as I worked my way up the layers of
modules, the higher I got, the more false+ I got when trying to only
make changes that preserved logical-constness.
Change-Id: I4acd2c4416775f7c6a3d91eb0bce048630ccaff5
This can also call loplugin::isSamePathname with two paths that both contain
backslashes, so finally make it (and hasPathnamePrefix) symmetric in which
arguments my contain backslashes.
Change-Id: I0465988d9d41e21c5660cbdbd1558543860ae1ad
