As Mike noticed, the pb is more general than just Base forms.
So here's the general fix suggested by Mike (thank you for the help!)
Change-Id: Ic57039c9c37f26d2ea2d0e0bda89f277ba7044cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171337
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Because I want to make more symbols private, but that runs into a
problem with the special symbol "typeinfo for Foo" which is required for
dynamic_cast.
For clang, we can use SAL_DLLPUBLIC_RTTI to make just that magic
"typeinfo for Foo" symbol visible.
But for gcc, we are left with no option but to make the whole class
visible via <MODULE>_DLLPUBLIC.
(I have a feature request logged against gcc to support something like
that at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958)
But I also don't want to use <MODULE>_DLLPUBLIC, since that blocks
progress of reducing symbol visibility for platforms other than gcc.
So map SAL_DLLPUBLIC_RTTI to visiblity:default for gcc, which means that
only gcc suffers the negative affects of not having that annotation.
However, that runs into the problem that gcc does not like
visibility:default in a couple of places, so I have to introduce some
extra preprocessor stuff.
Change-Id: Ib4fc5c1d2a1f8cf87d5159a4b5684137ec061605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164356
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which had been added all the way back in 2002 with
6cd0bbd8ce "adding new file to HEAD" to constants
group css.drawing.CaptionEscapeDirection, which has meanwhile been published, so
no chance of cleaning that up.
But cppumaker already has a mechanism to work around problematic UNOIDL
identifiers, but which was only used for "new-style" entities when they got
introduced, mainly to avoid compatibility issues when retroactively changing the
code generated for existing entities.
But for C++ keywords, the generated code was always broken, so no harm in fixing
it, so introduce an additional IdentifierTranslateMode::KeywordsOnly and use
that at least for constants, to address the immediate issue.
(And with that, a hack can be removed from gb_UnoApiEmbindTarget__add_embind.)
Change-Id: I5cf62fd8b3b298dff2ec28452fb97b424a4ba473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162305
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
For one, no need to wrap in #ifdef EMSCRIPTEN code that is only ever fed into
emcc anyway. For another, better use fully qualified names throughout generated
code, to avoid unexpected collisions.
Change-Id: I939728c7e0601e5fb3f3634bbd62f35042d91105
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162266
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
and
cid#1546284 Using invalid iterator
cid#1546275 Using invalid iterator
cid#1546049 Using invalid iterator
cid#1545929 Using invalid iterator
cid#1545870 Using invalid iterator
cid#1545668 Using invalid iterator
cid#1545420 Using invalid iterator
Change-Id: I3ad3000631b4be5917b9c5f49f21b8cc003a309c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159056
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and :
cid#1545537 Using invalid iterator
cid#1545508 Using invalid iterator
cid#1545494 Using invalid iterator
cid#1545478 Using invalid iterator
cid#1545427 Using invalid iterator
cid#1545420 Using invalid iterator
cid#1545400 Using invalid iterator
cid#1545300 Using invalid iterator
cid#1545258 Using invalid iterator
cid#1545257 Using invalid iterator
cid#1545200 Using invalid iterator
cid#1545183 Using invalid iterator
Change-Id: Ibf3a41902f34286967195c5c3b22e337a4b06809
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160322
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
https://en.cppreference.com/w/cpp/compiler_support says that this is
supported in
GCC >= 11
CLANG >= 16
Visual Studio >= VS 2019 16.10
And our Visual Studio baseline is now 2019.
We still need to make the ifdef conditional check clang, because
__has_include will happily return true even if the current clang
does not support the necessary builtins.
Change-Id: I5f2743e204b8ed22d4651053f3ae579a4a192a45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157515
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A rough implementation of uno bindings for LOWA using embind.
Adds new parameter '-W' to cppumaker to generate _embind.cxx
files alongside .hdl & .hpp.
For usage examples see static/README.wasm.md
Change-Id: Iee5d05e37bfba8e101c08212b15c05f7f2fa6c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156273
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
...and revert e1c6f36d8b "Add a to_string()
function to the code generated for UNO IDL constant groups". (But keep the
constants groups the latter had added to cppu/qa/cppumaker/types.idl, and use
them in the newly added CppunitTest_stoc_dump, for better or worse.)
Change-Id: I56e9eaeb1e45b83a72a25eceef13e719dc6f3a1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149281
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins
If the inpt matches one of the constants exactly, the result is the
name of that constant. If the input matches some combination of
constant values that are single bits, the result is the sequence of
the names of those constants joined with plus signs.
For instance, if the IDL has:
constants Constants {
const byte BIT0 = 1;
const byte BIT1 = 2;
const byte BIT2 = 4;
const byte BIT3 = 8;
}
The result of Constants::to_string(5) is "BIT0+BIT2", and the result
of Constants::to_string(17) is "17".
I am sure there are corner cases that aren't handled as would be
intuitive, especially with types that include unsigned values.
Correspondingly, the semantics of the generated to_string() functions
is not formally defined.
Also add a unit test for the new functionality.
Change-Id: I14aa826d0989ac6dfe97dd5c09119b1601c65643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148995
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
When 485c9d4f0e "Clarify the use of
untools::WeakReference" introduced cppu::detail::isUnoInterfaceType and its use
in the requires-clause of unotools::WeakReference::get, its commit message
argued that while isUnoInterfaceType only works if the given type is complete,
that would already be taken care of via the use of std::is_convertible_v in the
implementation of unotools::WeakReference::get. But while std::is_convertible_v
nominally requires its argument types to be complete (unless they are void, or
arrays of unknown bound), typical implementations like recent libc++ or
libstdc++ do not seem to enforce that (and just return false in such a case).
So better make isUnoInterfaceType explicitly require that the given type is
complete. Which turned up one case where it isn't at the point where
unotools::WeakReference<SdrTextObj>::get is called. (And while the resulting
call to dynamic_cast<SdrTextObj*>(...) in the implementation of that function
would cause an error when SdrTextObj is not complete, compilers happened to
instantiate that template specialization only at the end of the TU, by which
time SdrTextObj happened to be a complete type in the TUs including that
sd/source/ui/inc/futext.hxx. So all happened to work out OK.)
Change-Id: I704b8b437fa836e290245d1727e4d356128ef63c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143667
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which had been introduced in 78040af9ac
"loplugin:refcounting in sc" as a variation on css::uno::WeakReference from
include/cppuhelper/weakref.hxx, but without giving much of a rationale.
And, at least for --with-latest-c++ builds using a capable C++20 compiler,
ensure that the given interface_type is such that the static_cast and
dynamic_cast in the implementation of unotools::WeakReference::get are actually
sound: If interface_type could be a UNO interface type, that would imply that
the xInterface obtained from the underlying WeakReferenceHelper::get() could be
a proxy from the C++ UNO bridge, which could (a) be a proxy for only a subtype
of interface_type (e.g., just for XInterface), so that the static_cast would be
broken, and (b) be a proxy for which the vtable's RTTI slot is not set up (see
e.g. the ENABLE_RUNTIME_OPTIMIZATIONS code in
bridges::cpp_uno::shared::VtableFactory::initializeBlock in
bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx), so that the dynamic_cast
could crash. (These issues can even happen when the given interface_type is a
C++ implementation class type, but the given object has been bridged over some
C++ to C++ UNO ("purpose") bridge, but lets leave it at that...)
This required adding some cppu::detail::isUnoInterfaceType predicate to the
include files generated by cppumaker, which can be useful in other places too.
(For the call to isUnoInterfaceType in the requires-clause of
unotools::WeakReference<interface_type>::get to give the correct answer, it is
important that interface_type is a complete type---i.e., the corresponding
codemaker-generated .hpp having been included if interface_type actually were a
UNO include type. But that is already nicely required by the call to
std::is_convertible_v in the implementation of that function, anyway.)
Change-Id: Ia5efd70085d2d6d45fa0995d00dc8def564bbe5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143601
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 9463550eab.
Reason for revert: The codemaker::UnoType::decompose was previously mostly returning the same OString it receives, so this change is likely a pessimisation
Change-Id: Ie1b41889d0a6af9247b8683075d4edd1163fecc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133492
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For example, in de3898aecb "Add missing test
dependency" it would have output
> warn:svx:680849:680849:svx/source/unodraw/unoshape.cxx:1779: DBG_UNHANDLED_EXCEPTION in setPropertyValues exception: com.sun.star.beans.UnknownPropertyException message: "URL at svx/source/unodraw/unoshape.cxx:1600"
rather than
> warn:svx:680849:680849:svx/source/unodraw/unoshape.cxx:1779: DBG_UNHANDLED_EXCEPTION in setPropertyValues exception: com.sun.star.beans.UnknownPropertyException message: URL svx/source/unodraw/unoshape.cxx:1600
making it slightly clearer that what follows "URL" is not the value of that URL
but rather the source location where the exception was thrown.
Change-Id: Ia3abd232fce3d95a8b66ff4ed5bab2fcc248df2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128788
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The legacy `throw()` dynamic exception specification is gone for good from C++20
(even if compilers typically still accept it, but e.g. Clang has
-Wdeprecated-dynamic-exception-spec to at least warn about it).
Introduce SAL_NOEXCEPT for use in URE interface include files. (For both the
existing SAL_THROW_EXTERN_C and the new SAL_NOEXCEPT, base usage of `noexept`
not on LIBO_INTERNAL_ONLY, but on the actual compiler C++ version, so that e.g.
building CppunitTest_cppu_any-external, which uses
gb_CppunitTest_set_external_code but not gb_CXX03FLAGS, will not potentially
complain about those macros expanding to the legacy `throw()`, like when
building with Clang -Wdeprecated-dynamic-exception-spec manually enabled.)
Change-Id: I7e5c7f8d5f0fd622cfc9987d656b1f68541375aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114908
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Clang and gcc have moved this out of experimental and into std::source_location,
but only in their very latest releases.
Change-Id: I9d9d9155788ee4240455ac4628b298dface4ad24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93868
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
if one side of the expression is a compile-time-constant, we don't need
to worry about side-effects on the other side
Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b
Reviewed-on: https://gerrit.libreoffice.org/81589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Gabor Kelemen