<https://gerrit.libreoffice.org/c/core/+/144139> "New loplugin:unocast" had
argued that uses of dynamic_cast from a UNO interface type are broken in general
(because if the source object is a proxy from the C*+ UNO bridge, its vtable's
RTTI slot will normally not be set up, which can cause a crash), and should be
replaced with uses of XUnoTunnel. Which the various recent "loplugin:unocast
(...)" commits started to do. However, it became clear that that is not the
most ideal way forward: For one, getting more and more implementations of
XUnoTunnel::getSomething into existing class hierarchies is error prone, as each
such implementation must manually delegate to all its base class
implementations. For another, uses of comphelper::getFromUnoTunnel (which often
needs to do a queryInterface to XUnoTunnel first) are easily more expensive than
uses of dynamic_cast.
Thanks to Noel, the insight here is that for the use case of a dynamic_cast from
a UNO interface type to a local C++ class type, and if the source object is a
proxy, it is sufficient that the dynamic_cast will not crash. It will
necessarily always return null (as the proxy will never be the implementation of
a local C++ class type), so it is sufficient to fill the RTTI slots of the
proxies' vtables with dummy values. That avoids having to set up proper RTTI
for those potentially multiple-inheritance proxy types. (And with this in
place, all those recent "loplugin:unocast (...)" commits can be reverted again
in a next step.)
I verified the changes for the gcc3_linux_aarch64 (on macOS), gcc3_linux_intel,
gcc3_linux_x86-64, gcc3_macosx_x86-64, msvc_win32_intel, and msvc_win32_x86-64
bridges. The changes for all the other bridges were done blindly.
(For gcc3_linux_x86-64, which already conditionally supported proper RTTI for
UBSan, setting the offset-to-top slot to non-zero had to be made conditional
too, as the dummy ProxyRtti will always pretend to be a full class rather than a
potential base class that could have a non-zero offset-to-top value. For
msvc_win32_*, it turned out that the existing code to set up dummy XInterface
RTTI (which was there for reasons lost to history) was broken.)
Change-Id: Iec4b8067d26b14b6fb02c2fdd15e1eee20919590
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145038
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 739aaf02db. At least in
bridges/source/cpp_uno/gcc3_macosx_x86-64/except.cxx, getRTTI can call itself
recursively, causing a deadlock on RTTI::m_mutex. In
bridges/source/cpp_uno/gcc3_linux_x86-64/rtti.cxx that has been addressed with
RTTI::getRTTI_NoLock, but other implementations have not been modified. Avoid
regressions, esp. on more esoteric platforms, by reverting the change.
Conflicts:
bridges/source/cpp_uno/gcc3_linux_x86-64/rtti.cxx
Change-Id: I08b57b0561923bdbe191c8e93f8f400e0e4df337
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119442
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
First, make sure existing compiler-generated RTTI from liblo-native-code.so is
found (so that catching bridge-synthesized exceptions in native code works with
libc++abi, which checks type equivalence by address instead of string
comparsion), by using the dlsym(RTLD_DEFAULT,...) mechanism as in the ANDROID
gcc3_linux_arm bridge case. And second, if that should fail, synthesize the
type_info even if the included cxxabi.h doesn't provide the relevant type
declarations, by using copies from the ABI specification, as also done on other
platforms.
Instead of always having getRTTI fail and raiseException throw a non-synthesized
css::uno::RuntimeException("no rtti for type ..."). Which explains the mystery
discussed in the commit message of 312eeeee42
"Switch Android armeabi-v7a to libc++/libc++abi/libunwind too", why the observed
misbehavior on x86 was so different from that on armeabi-v7a.
Change-Id: I9308654c5c2b88b4d27e0e8e9edda1849133a161
Reviewed-on: https://gerrit.libreoffice.org/65070
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it
arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later
Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79
Reviewed-on: https://gerrit.libreoffice.org/45163
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
... except in include/rtl, include/sal, include/uno, where sal_Size is
retained for compatibility, and where callers of rtl functions pass in
pointers that are incompatible on MSVC.
Change-Id: I8344453780689f5120ba0870e44965b6d292450c
This reverts commit f5792667ca.
it turns out it was the use of an intermediate GtkGrid which made a11y work
a little differently under gtk3. Clearly not intended to be pushed.
Change-Id: I6931163e07ea413acdd45ba1353f357d317fdfbd
In bridges/source/cpp_uno/gcc3_macosx_x86-64/share.hxx, the #if also covered
Clang, which actually needs these declarations (for now; the right fix will
probably be to #include <cxxabi.h>).
Change-Id: I1eebd59e2371f3498d740ab78244927358c4f23f
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx>
(and don't make use of it themselves), but many other files happen to depend on
it. Cleaned up some, but something like
grep -FwL sal/log.hxx $(git grep -Elw \
'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF') -- \*.cxx)
shows lots more files that potentially need fixing before the include can be
removed from rtl/string.hxx and rtl/ustring.hxx.
Change-Id: Ibf033363e83d37851776f392dc0b077381cd8b90
as an experiment to see if that's somehow the cause of
NEXT An uncaught exception of type com.sun.star.sdbc.SQLException
NEXT - General error: java.lang.UnsatisfiedLinkError: com.sun.star.sdbcx.comp.hsqldb.StorageFileAccess.isStreamElement(Ljava/lang/String;Ljava/lang/String;)Z
NEXT ##Failure Location unknown## : Error
Test name: HSQLDBTest::testEmptyDBConnection
NEXT An uncaught exception of type com.sun.star.sdbc.SQLException
NEXT - General error: java.lang.UnsatisfiedLinkError: com.sun.star.sdbcx.comp.hsqldb.StorageFileAccess.isStreamElement(Ljava/lang/String;Ljava/lang/String;)Z
under clang
This reverts commit ce7f442bd0.
Change-Id: Ieed0be5721953b9644e4be411173e0ea73f33ed8
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
Stephan Bergmann