first, since those are safer to change than virtual methods
Change-Id: Ie3b624019d75ee2b793cee33b3c5f64e994e8bfe
Reviewed-on: https://gerrit.libreoffice.org/45798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In this first commit, I use the plugin to verify the consistency of our
SAL_CALL annotations.
The point being to make the next commit more mechanical in nature,
purely using the rewriter.
There are various chunks of unix-only code that have never had to be
compiled by MSVC, hence the inconsistencies.
In bridges, I had to inline some typedefs to make the verification code
happy, since it cannot see into typedefs.
Change-Id: Iec6e274bed857febf7295cfcf5e9f21fe4a34da0
Reviewed-on: https://gerrit.libreoffice.org/45502
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...preventing the dtor from ever being called. (DocumentEvents forwards its
acquire/release calls to its m_pData->rParent, i.e., the ODatabaseDocument, for
better or worse.) This caused ODatabaseDocument instances to be leaked during
e.g. JunitTest_dbaccess_complex. Regression introduced with
de2ac128da025502c533f8cede5862e054dd9c44 "loplugin:useuniqueptr in dbaccess".
Change-Id: Ida073c7e576b88e0d1d1a90253445e946e6eac99
Reviewed-on: https://gerrit.libreoffice.org/45652
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The mnRequestedLength fields in formula/ were introduced in
commit 6ef6dd0122b8e44d8547ec31f40def42173e4e41
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date: Wed Feb 26 14:32:57 2014 -0500
Store the length of originally requested array size prior to
trimming.
but then partially removed in
commit d7f1f91b194da1cb96e66268ce7ef38602aa5754
Author: Noel Grandin <noel@peralex.com>
Date: Mon Mar 3 13:29:43 2014 +0200
remove unused code in formula/vectortoken
Change-Id: Ic56b6e42682131ee45df7838867145f980f3d601
Reviewed-on: https://gerrit.libreoffice.org/45571
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...after bc4e8de8eea1ccebda479c8e2db2f3c6dfff60d2 "Silence new
loplugin:fpcomparison for now":
> Nov 30 08:33:16 <sberg> noelgrandin, thoughts on whether fpcomparison is actually worth it, seeing the loooooooong blacklist there?
> Nov 30 08:34:11 <noelgrandin> sberg, that's wasn't my idea, can't remember who came up with it. vmiklos was that you?
> Nov 30 08:34:36 <noelgrandin> sberg, the original commit message was "Find code that compares floating point values with == or !=
> Nov 30 08:34:36 <noelgrandin> It should rather use rtl::math::approxEqual"
> Nov 30 08:34:45 <noelgrandin> so in theory the replacement should be fairly manual
> Nov 30 08:34:48 <vmiklos> i don't think so :)
> Nov 30 08:35:15 <noelgrandin> might have been moggi, but he's not around so.... just disable it
> Nov 30 08:36:19 <sberg> noelgrandin, yeah, in theory; in practice, I guess there's also cases where x==1.0 is what you want exactly (given x tends not to be a computed value after all, but some literal that's being passed around)
> Nov 30 08:36:33 <sberg> noelgrandin, yeah, I'll disable it then
Change-Id: I35f5328efa0ec02d9be837c12efab2b03a3dae52
Reviewed-on: https://gerrit.libreoffice.org/45550
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
for some reason we're hitting more template AST nodes now? Anyhow,
updated singlevalfields and unusedenumconstants to cope.
For unusedfields, ignore field access inside Clone() methods, since it's
like a constructor.
Similarly for unusedmethods.
Change-Id: Icb2f76fb2f06ae5df21f9d75312e42a2800befb9
Reviewed-on: https://gerrit.libreoffice.org/45470
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...taking care not to warn about those cases that are used to silence Clang's
-Wunreachable-code
Change-Id: I3c1da907f51cc786f81c1322fe71d75832cd9191
Reviewed-on: https://gerrit.libreoffice.org/45521
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as those may be used to silence Clang -Werror,-Wunreachable-code (as happens
in sal/osl/unx/file_volume.cxx for Android, where OSL_detail_STATFS(...) always
expands to (1)).
Change-Id: I85d280c1315b4447362255d17f13f437d3c4af92
...that are not composed of multiple tokens, like ("foo" "bar"). Also don't yet
warn about Boolean literals, which are sometimes wrapped in parentheses to
silence unreachable-code warnings.
To avoid multiple warnings about code like
f((0))
switch to generally using a set of ParenExpr to keep track of which occurrences
have already been handled.
Change-Id: I036a25a92836ec6ab6c56ea848f71bc6d63822bc
Reviewed-on: https://gerrit.libreoffice.org/45317
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>
* rsc/source/parser/rscyacc.cxx no longer exists
* writerfilter/source/rtftok/rtftokenizer.cxx appears to be just fine nowadays?
* sw/source/filter/html/htmltab.cxx used redundant parentheses around a comma
operator in a while condition, and I see no reason not to remove them (the
result requires a---reasonable---tweak to loplugin:commaoperator, though)
Change-Id: I451132c700b0ae5a43b03d704156484df897ad5c
Reviewed-on: https://gerrit.libreoffice.org/45213
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
