Because it's used only for LOK, and SvpSalVirtualDevice::CreateSurface()
otherwise wouldn't know whether to apply LOK DPI settings or not
(since this might be called for LOK tiled painting, when it should,
or it might be called from somewhere else while LOK is active, in which
case this should be handled normally). Getting that mismatched can cause
things like https://github.com/CollaboraOnline/online/issues/4834 .
Change-Id: I1df7b8a169c8ef2e799731a6695a032948536582
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135588
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* Client code must replace uses of idlc and regmerge with uses of unoidl-write,
see the changes to odk/examples/ and ure/source/uretext/ in
40f2aee658 "Provide unoidl-write also for the
SDK" for examples.
* The new types.rdb format is not compatible with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
* For compatibility with old extensions, reading the legacy types.rdb format is
still supported.
* The SDK no longer ships an idl/ sub-directory containing the udkap and offapi
.idl files (as, unlike idlc, unoidl-write does not need them).
odk/config/cfgWin.js had to be adapted to look (somewhat arbitrarily) for an
examples/ sub-directory instead of idl/ when checking for "an sdk folder".
gb_UnoApi_package_idlfiles became unused and has been removed.
* The idlc and regmerge executables have been removed. Module idlc has been
removed except for idlc/test/parser/, which is also used by
CustomTarget_unoidl/unoidl-write_test, and which may eventually be moved into
module unoidl. Module external/ucpp and the corresponding configure options
have also been removed.
Change-Id: I42a0231699b863b5ebe2bee63bc32c8f79278cc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for local variables that can be std::move'd to parameters
off by default, since it doesn't do proper data flow analysis
Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... and use it to remove a duplicate and simplify code.
Should mostly be a refactoring, which was mainly done by some
larger sed calls, except for the new API calls, which helped
shrinking some LOC. All data is also now private.
Originally two of the "replaced" "classes" had unsigned width
and height and one had signed. Noel pointed out, that during
calculations, the value might get negative temporarly, so this
now settles with signed values. Still the set size should never
be negative and this is enforced this way. Not sure that is what
Noel had in mind.
This also includes:
- rename WindowState => WindowData
- rename WindowStateMask => WindowDataMask
- rename WindowStateState => WindowState
- move WindowState and WindowDataMask to vcl/windowstate.hxx
- move WindowData(Mask) and WindowState into vcl namespace
- readability: replace or'ed WindowState enums with "meta" enums
+ add "meta" WindowState enums PosSize and PosSizeState
Change-Id: Icd16cfb498531aa7238ddbde83fcb0ed6d9e4f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135426
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(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>
...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>
...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>
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>
...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 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>
Andrea Gelmini