Extract some dummy implementations for XCanvasFont methods
from cairocanvas::CanvasFont to a new CanvasFontBase base
class. That will allow reusing them in other XCanvasFont
implementations that currently have equivalent implementations
for those methods by themselves.
That allows to deduplicate code a bit.
Change-Id: I964330de605368eaa665c1ddc60db7b6e45d9fcb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208848
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
At least some IDEs are confused by our multitude of `tools` namespaces,
and show errors like `namespace "tools" is ambiguous`.
This removes one such namespace. The idea is to drop all but the one
in /tools (that has tools::Long and tools::Rectangle).
Change-Id: I6077f50ad0fcc49abfadc75d9948ab63df829ff9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189948
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I9467028fd1a7eeafad7f0dd776a91a9a40770b48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166816
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I965d6ba17decda1fa055fb548aa9085d2e786bc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144768
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I472e09870b51b89b89c643675ab46c38b4a0c6de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144753
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...assuming that such an exception is rare enough that any performance impact
does not matter. (The code was like this ever since its introduction in
9e2bf1d54a "INTEGRATION: CWS canvas02".)
This nicely avoids loplugin:unusedmember about unused mpStr and mnArgPos when
OSL_DEBUG_LEVEL is zero.
Change-Id: I2ad3e36e98a6811ae255525cf8159db89c78ad7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100143
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Jenkins
...as discussed as an open TODO in the commit message of
fe6cce01c8 "Fix loplugin:simplifypointertobool for
libstdc++ std::shared_ptr". The necessary changes across the code base have
been done fully automatically with the rewriting plugin on Linux. (All those
changes apparently involve uses of macro arguments wrapped in parentheses in the
macro body, but always in conditionally-converted-to-bool contexts. In other
contexts, such automatic rewriting would add the "bool" to the macro body, which
would be wrong in general, but we apparently get away with that sloppy coding
for now.)
The parenExprs_ stack that fe6cce01c8 had
introduced to treat such (then-undetected, it had turned out) parenthesized
cases now turns out to not be needed after all.
Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
introduced with
commit 17cd7dd708
tdf#43671 set emphasis mark of vcl::Font (windows).
but has probably never been a problem because I guess this
propertyset almost always has 0 or 1 element.
Change-Id: I17c64e376ee81cc9f92173015d2632331c63ae0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93643
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The main reason for the "home-grown" UpCast introduced with
904b3d1fce "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fe "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Michael Weghorn