off by default, since each warning needs careful inspection
Change-Id: I805c1d1cdde531a1afdc76e87b22f879fc3c9753
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134641
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(in preparation of extending loplugin:redundantcast to more reinterpret_cast
scenarios, which would have caused a false positive here). Required a tweak to
loplugin:fakebool (as the relevant reinterpret_cast to silence some occurrences
is no longer seen "inline" now), and the heuristics of loplugin:unused no longer
worked (also because of the now-hidden reinterpret_cast'ing), but adding a
maybe_unused attribute looks better than tweaking that plugin's heuristics even
further.
Change-Id: Iead1a9b31983918cf8f3b0e6c727c0081437c6d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134504
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There is just no good reason not to use a css::uno::Any constructor instead, so
simplify the code base. For URE backwards compatibility, keep it around as
deprecated for !LIBO_INTERNAL_ONLY.
Change-Id: I9409d8853cac270d47377a31ba35a1fc23fa9800
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133879
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to find places where string_view is pointing into a temporary String
Change-Id: Ib530b36f441e95d83d8f687d40a97516a0806721
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133656
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...by annotating occurrences of false warnings with [-loplugin:<name>] comments
in source files and letting individual plugins opt-in to watch out for such
suppression annotations, rather than maintaining lists of excluded source files
in the individual plugins. (See the new loplugin::Plugin::suppressWarningsAt.)
Instead of making all calls to loplugin::Plugin::report check for suppression
annotations, the intent is that this check will only be added opt-in to those
places in the plugins that are prone to emitting false warnings. In general it
is better to have plugins that don't produce false warnings in the first place,
or at least let those warnings be addressed with trivial and harmless source
code modifications, avoiding the need for any suppression mechanism.
As a proof of concept, I have removed the exclude list from
loplugin:redundantfcast and instead annotated the relevant source code. (And
thereby found that three of the six originally excluded files didn't need to be
excluded any more at all?)
For now, this mechanism looks for comments (both //... and /*...*/, even
documentation-style /**...*/) that overlap the current and/or the preceding
line, because at least for code controlled by clang-format it is often easier to
move comments to a line of their own, preceding the commented code. Looking
also at the current line (and not only at the preceding one) opens the door for
erroneous over-eager annotation, where an annotation that was meant to address a
false warning on the current line would also silence a potentially true warning
on the following line. This probably doesn't cause much trouble in practice,
but is up for potential change.
Change-Id: I91ce7a0e5248886a60b471b1a153867f16bb5cea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133365
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
With previous implementation, empty spaces between dashes
were too long.
Additionally line joints were not working correctly, after
EMF+ reworking: tdf#111486
This commit fixes all these issues and additionally it is
covering it with tests.
Change-Id: I9404e566d2d7d3405ab817268ad9b1f538c200eb
Change-Id: I523f92a928ab592ff175d0d01c1ad1a3bc22e324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133207
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
... that can be string_view
Change-Id: I0ddf66725e08b58e866a764f57200dd188b9f639
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133066
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to make those char class array initializations more readable. (Making the
corresponding variables constexpr is mostly done so that failures in the
provided `unencoded` arguments, like non-ASCII characters or duplicate
character typos, would lead to compile-time errors also for !HAVE_CPP_CONSTEVAL.
And assigning to a sal_Bool std::array needs another hack to avoid false
loplugin:implicitboolconversion warnings.)
Change-Id: Ieb8827f69f55f1212a9428817d5331fcb18ef1d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and add tests for those additions to isBoolExpr done in
8e4d82cd11 "loplugin:implicitboolconversion: warn
about conversions to unsigned char" (and which were added to avoid false
warnings like
> testtools/source/bridgetest/bridgetest.cxx:643:21: error: implicit conversion (IntegralToBoolean) of call argument from 'unsigned char' to 'bool' [loplugin:implicitboolconversion]
> (xLBT->transportPolyBoolean(
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
and
> cui/source/options/optaboutconfig.cxx:359:62: error: implicit conversion (IntegralToBoolean) of call argument from 'unsigned char' to 'bool' [loplugin:implicitboolconversion]
> sValue.append(OUString::boolean( seq[j] ));
> ^~~~~~
)
Change-Id: I0683144e1c39d31303faf678afaafd708ef7ff79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133018
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
where we can convert that to
o3tl::toInt32(o3tl::getToken(
and avoid the heap allocation of a temporary string
Change-Id: Ib11c19c6e6cdc0de3e551affd3578d181e292de4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132810
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
since we now have o3tl versions of those that work on
string_view.
Also improve those o3tl functions to support both string_view
and u16string_view
Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
for which we add a new o3tl::trim method
Change-Id: I9d37b6264eea106aa2f3502bd24b8cccf7850938
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132658
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...so that e.g. building on F36 with -stdlib=libc++ doesn't fail with
> i18nutil/source/utility/paper.cxx:311:75: error: NullToPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr]
> locale_t loc = newlocale(LC_PAPER_MASK, "", static_cast<locale_t>(0));
> ^
when the locale_t typedef declaration is nested in extern "C" (from
/usr/include/stdlib.h) which in turn is nested in extern "C++" (from LLVM's
include/c++/v1/math.h)
Change-Id: Ie81d7425cda231954bdbab47c3a0431dc7c27f5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132520
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which converts to a combination of substr and o3tl::starts_with
Change-Id: I5b01a181b9e6bee3483e4f49f1a9426abcc682d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132458
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
.. and lastIndexOf, which convert to find and rfind
Change-Id: I6c4156cf904774c0d867f85a4c2785dba7593f62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132445
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which was apparently meant as a "Possible debugger breakpoint" in
DBG_UTIL-only sw_DebugRedline. The obvious fix is to mark nDummy as volatile,
but increment of a volatile variable is deprecated, so replace those with reads
of the variable, but which triggered false loplugin:casttovoid so fix that too.
Change-Id: I07376e665caa4fd9befaba06d261a50df7a63a10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132237
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which appears to have become even less relevant with
db89f53c31 "remove OpenGL VCL backend code". And
the vcl/unx/glxtest.cxx machinery that it is based on is (a) known to cause
issues like <https://gitlab.freedesktop.org/mesa/mesa/-/issues/3957>
"LibreOffice's OpenGL version detection code hangs when running inside a flatpak
container with a different mesa version", and (b) is one of the two reasons why
an soffice that uses Wayland nevertheless also requires Xwayland during startup
(the other reason being oosplash). So getting rid of the glxtest machinery is
beneficial.
The remaining two potential uses of OpenGL on X11/Wayland are the obscure
css.rendering.SpriteCanvas.OGL service implementation (about which
db89f53c31 states that "it seems has never been
finished or enabled (or so it most probably should be dumped too)") and some
slideshow transitions. About the latter, Caolán stated on IRC: "I think we
grew this set of stuff to check for dodgy opengl primarily for the case where
vcl used opengl for ordinary UI optimizations; but I think that use is gone now
so I wonder does it make sense to just drop all of that entirely; for just slide
transitions we apparently survived fine without the denylist for ages". (And in
any case there is still the WatchdogThread support with OpenGLZone::hardDisable
in VCLExceptionSignal_impl, vcl/source/app/svmain.cxx, should any OpenGL code
run into problems.)
(The removal of gb_LinkTarget_use_glxtest from gb_LinkTarget_use_vclmain, which
indirectly brought in gb_LinkTarget_use_libraries,*,vcl, revealed that an
explicit use of vcl was missing from various Executables etc., which thus had to
be added now.)
Change-Id: Ifa5220fd09910a4459ca546d9655e479a2e38f1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131943
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where the S4 template constructor may still have an unparsed null body, so
if (!constructorDecl->hasTrivialBody())
return true;
will suppress the expected warning. Lets just accept that clang-cl on Windows
will find less instances of loplugin:trivialconstructor. (And moving the
expected-error comment around on the line was demanded by clang-format. Oh my.)
Change-Id: I3357fbd0fbf932f7f93c421c2f079a8cfc536eef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132019
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(1) sanitize call value output, make downstream processing easier
(2) remove bad ignoreLocation() call, which was eliminating a lot of
valueable data and thus generating false positives
Change-Id: I39230c260c5cf717559300913fbc68bc3485b957
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131986
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(The template default constructor in S8 had already been suppressed via
std::distance(recordDecl->ctor_begin(), recordDecl->ctor_end()
being zero, but the similar case in S7 caused a warning.)
Change-Id: I4d18dec8bb971198eb8503262572a08c019c66bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131663
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The recursive checking of (non-virtual) bases and the checking of all virtual
bases were unnecessary. It suffices to just check whether all the direct
(virtual and non-virtual) bases have trivial destructors.
(And FieldHasTrivialDestructor*Body* was a misnomer, as it actually checks
whether the corresponding type has a trivial destructor.)
Change-Id: I8a70e18eea4b629ad56577fa885f51925f9d7dde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131608
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
No idea what this "The destructor for an implicit anonymous union member is
never invoked" block was meant to be good for.
If a union-like class X has a variant member Y with a non-trivial destructor, an
(implicitly-declared) defaulted destructor of X would be defined as deleted, so
we must not warn about a user-provided destructor of X with an empty body. But
that is already covered by the fact that the anonymous union of which Y is a
member will have a non-trivial destructor if Y has a non-trivial destructor.
Change-Id: Ia30381a07fadd3132f5595575716c6c5097fa34d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which happens to be covered by
if (!destructorDecl->hasTrivialBody())
return false;
Change-Id: Ica2874e710da08d668b7e773373a1188a8ae16a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131575
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
If there's e.g. an entire row bold, it's enough to set default
attribute for unallocated columns.
This also reverts the workaround from commit 297ab561c6, as it's
no longer necessary.
Change-Id: I0b208709aeaff1c0d59da2410926876715cfe642
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131320
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
look for potentially trivial destructors that can then be elided
Change-Id: I435c251bd4291b5864c20d68f88676faac7c43fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131318
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
