Rudimentary support for dynamic_cast on UNO proxy objects

<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>

0 files changed, 0 insertions, 0 deletions