Age | Commit message (Collapse) | Author |
|
Alternatively we could just remove lots of stuff that we apparently
don't actually need from this file, including the problematic typedef
and its uses.
_Unwind_Exception_Class now gets typedeffed in <unwind_itanium.h> as
uint64_t which effectively is the same as the unsigned
__attribute__((__mode__(__DI__))) that is used here.
Change-Id: Id96d43eb481ee4ae97dd315aa2fd741e5f627916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150702
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
the stack variable doesn't point to the beginning of the array with the
values, instead the code creates a large general purpose register array (gpr)
with the floating point register (fpr) and stack just being offsets in
that one.
bridge isn't fully working with that fix yet, still some wrong pointers
ending up in the interface reference
Change-Id: I6f1e5f84f84aff34663090c20fe70d65e0a7a334
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150578
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I10b450bccf27304530767cf80e0a6b04768cfc80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150468
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib35058e0e8d1708c29f4fe727eda05f5a6de4ab4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150232
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
after my patch to merge the bufferadd loplugin into stringadd
Change-Id: Ieb9b4f5154173738e26b429b55c7a3ea38733553
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149478
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4c08ea2e464164351ba66a4c04ef2575e3f5f580
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149157
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I94686f820e264867643bb30c83367ee702d3118d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149088
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1893e130af2584c1d57c3e37ee3f3ff18c07c077
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148792
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Missed in 7a8ec6cddc9f37ba6ff1a98ad39702521c8fb36b
Change-Id: I70b73873f20814d25c34f326a6552e72f57b3e28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149081
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: Ibd3b9a76b700a5efbf7855454714646daf612d13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147675
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Relevant announcement from revision history for NDK 23 [1]:
> * GNU binutils, excluding the GNU Assembler (GAS), has been removed. GAS
> will be removed in the next release. If you are building with
> -fno-integrated-as, file bugs if anything is preventing you from
> removing that flag.
Therefore, switch from uses of GNU binutils to the
corresponding LLVM tools instead.
NDK 20.x doesn't provide `llvm-ranlib` yet, so bump the minimum
version to 21.x.
Also drop the previous uses of `ANDROID_BINUTILS_PREBUILT_ROOT`,
which appear to no longer be relevant by now.
commit 4082a18406c18af7b4fcef7bd501c3679c3be56b
Date: Wed Nov 22 23:08:06 2017 +0100
android: use unified headers and llvm-c++ STL (x86) with NDK 16
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
that introduced one of those uses mentions issues on ARM, but building
and running the app at least on my 32-bit ARM device (Samsung Galaxy S4 I9505,
LineageOS 17.1/Android 10) didn't show any issues in a quick test
with this change in place.
Update the Jenkins config to switch from the now no longer
supported NDK 20.1.5948944 to 23.2.8568313 for which building and
running the app has been tested on devices for all of the four
supported architectures with upcoming change
Change-Id I9ea714255faf29d50bb5f8e206f13495637da867
"android: Require NDK 23 and use default linker lld" in place
on top, s. that one's commit message for more details.
Note however that the NDK version will be further updated to use
NDK 25 in upcoming change
Change-Id Ib8e65f433ee89ff1bc12432722570bf8f9f7ed85
("android: Support NDK 24.x and 25.x, use NDK 25 for Jenkins").
[1] https://developer.android.com/ndk/downloads/revision_history
[2] https://lists.freedesktop.org/archives/libreoffice/2023-January/089878.html
Change-Id: I7645f8025d42f0fa384b5bceb31bb4b1c0a44cb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146118
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: Iab6d430af7afc0d21e118b05d64a15664fc2f677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146469
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic947b58b9aba121c605b6795c7cd9aa0b16b180e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementations at bridges/source/cpp_uno/gcc3_solaris_intel and
bridges/source/cpp_uno/gcc3_solaris_sparc are apparently dead and should thus be
removed. Those were the only bridge implementations for Solaris, but the
referenced thread mentions that there are recent builds for OpenIndiana x86-64
(however they are done; presumably using
bridges/source/cpp_uno/gcc3_linux_x86-64), so keep general support for Solaris
intact for now.
Change-Id: I09ec098f5509f25a126342536745509bbe9faaac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146059
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is
apparently dead and should thus be removed. However, that was the only bridge
implementation for 32-bit S390, which implies that support for the 32-bit S390
architecture as a whole is dead and should thus be removed.
Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Some failed test are caused by the bridges when testing on the
loongarch64 machine. After adjust the function parameters and return
value processing according to the characteristics of the loongarch64
architercture. I tested in version 7.4.3 on the loongarch64 machine, and
all tests passed.
Change-Id: I9c67287cd7cc89fd79a907afdbffa507bb6052e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144986
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
<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>
|
|
Our use of bridges::cpp_uno::shared::VtableFactory::Slot to model all the
elements of a vtable is an abstraction that doesn't quite match the reality of
<https://itanium-cxx-abi.github.io/cxx-abi/abi.html>, as vtables are not
homogenous sequences of function pointers, but are rather a mix of offsets, data
pointers, and function pointers.
The data preceding the virtual table address point is the offset to top (an
offset) followed by the typeinfo pointer (a data pointer). On other platforms
where offsets, data pointers, and function pointers are all of the same size, we
model those as two additional Slots at index -2 and -1, resp. On Itanium, where
function pointers (and thus Slots) are twice the offset and data pointer size,
we should model those as one additional Slot at index -1.
The code has been this way ever since its introduction in
0c25631972809c752624b4883c71671c8e83e797 "INTEGRATION: CWS ia64port01_DEV300
(1.1.2); FILE ADDED". It should never have caused any issues as the existence
of the excess Slot at index -2 should never have gotten in the way. But it is
probably better to clean this up anyway. (This is a blind fix, as I don't have
an Itanium build environment available. And this Itanium bridge may well be
dead code by now, anyway.)
Change-Id: I98d58785c054e1cdc621e5968c41b06d8788998f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145035
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
1. Configure gbuild
2. Add UNO Bridge for riscv64
Till now base function works well on riscv64. The bridgetest has passed.
Test on Debian, Gentoo and openEuler.
Credits:
- Heiher <r@hev.cc> and Stephan Bergmann <sbergman@redhat.com>
The riscv64 bridge implementation refers to mips64 and
AArch64 bridges.
- Bo Yu <tsu.yubo@gmail.com> configures gbuild for riscv64.
- WANG Xuerui <xen0n@gentoo.org> provides lots of guiding tips.
Change-Id: Ifad3b0de8b2c9e7328627ed03396bbd45a9c71e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137445
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Avoid the use of unnecessary local variables to temporarily keep
return values from a function called by the inline assembly. Instead
use the GPR and FPR arrays also to temporarily keep such return
values, like the Linux aarch64 code does.
This fixes https://github.com/CollaboraOnline/online/issues/5204
Change-Id: I11aac56e9c8cc8aff1a3653ced45bdf4844cbcca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139604
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I295d7877100b49a867a0f67e2edcc923d943401b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138664
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I846746a351c619a4de7abce7a6443f510dc41690
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138661
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9374a580d3dce7c7851881ff8193946d46ed2bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138384
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1b73d68b007ba0dfa54f99ff8f8fea55e94a1ed2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137651
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Loongarch is a new RISC ISA , which includes a 32-bit version and a 64-bit version, Here are some documents about Loongarch:
https://github.com/loongson/LoongArch-Documentation.
The loongarch64 bridges implementation refers to mips64 bridges, and the code related to abi and asm has been modified
Change-Id: I1d9cd3aadf63046c8cdecc9a64842567bfa1cecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137486
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I5b7a0fa060c1e0ae4aa194e0c1862f303dd8a2d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138062
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
as that what it actually is and the compiler defines are already
-DMIPS/-DMIPS64 anyway (as are the PLATFORMID and the bridges'
name mips/mips64)
Change-Id: I274e7a3b0e140375a8e697c1790cbdb972251d29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137489
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: René Engelhard <rene@debian.org>
|
|
Change-Id: I7bd02dba44a8bc62da660bcb7500960ef14172a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136939
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Ie8c04a8c414f32cc0e68fbab1d24a9707f179011
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136201
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6c52316e46117aacb22a2adcb75841aed834041f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134705
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by inspecting call sites of OUString::getToken
Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4bd3efe67217a4c4418cf308cc8e7a55cf4a604a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133390
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I842668655dec102e1595dcbac6413fe2b49d8515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133268
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I07b215067b1cefc87919680fad3299d702ff6d1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132100
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...that had been introduced with 7e8e85adbee73346403c364326544487677cd5c6 "Add
codeSnippet debugging output when dbglevel>1" and reinforced with
6f121860d0537060084278da11842732a748d6b7 "tdf#130924 replace debugging printf
calls with SAL_INFO/SAL_WARN"
Change-Id: I9529bfdedd3d1a3dd623fdb28e01d6bd96c92d97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131169
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iaef5eec6508d031ab711a71c0d8ecebb18112ef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130764
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...when building on Linux with Clang -stdlib=libc++,
> In file included from bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:41:
> bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx:156:51: error: Replace legacy dynamic 'throw ()' exception specification with 'noexcept' [loplugin:noexcept]
> extern "C" __cxa_eh_globals * __cxa_get_globals() throw();
> ^~~~~~~
(The situation with respect to these exception specifications is a bit unclear,
recent <https://github.com/itanium-cxx-abi/cxx-abi/blob/main/abi-eh.html>
doesn't mention any exception specifications for those effectively extern "C"
functions, and recent
<https://github.com/llvm/llvm-project/blob/main/libcxxabi/src/cxa_exception.h>
doesn't have an exception specification for __cxa_get_globals and recent
<https://github.com/llvm/llvm-project/blob/main/libcxxabi/include/cxxabi.h>
doesn't have one for __cxa_current_exception_type though it has `throw()` for
__cxa_allocate_exception. On the other hand, recent
<https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi.h>
and
<https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi_init_exception.h>
have _GLIBCXX_NOTHROW exception specifications for all three functions, which
expands to `noexcept` for C++11 and beyond.)
Change-Id: I1582c9d3b42977af011d4dc49674fdf12d5ea5ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130926
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... and use the same fake exception rethrowing code then the
mobile platforms.
Change-Id: Ic90de1cfd1e0092d6064d041a613d60d9f5f76b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128596
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It missed some occurrences of 0 when only looking into uninstantiated template
code, as Clang doesn't model them with an ImplicitCastExpr, even if the target
is known to be a (dependent) pointer type.
Looking into all template instantiations of course carries the risk that a given
use of 0 is meant to be interpreted as a pointer in some and as an integer in
other instantiations. But the only case where that happened in the current code
base is RegistryValueList::getElement (include/registry/registry.hxx), where {}
is arguably a better choice anyway. (And which would presumably also hold for
any future such cases.)
Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
copy and paste recommendation from:
https://sourceware.org/annobin/annobin.html/Test-cf-protection.html
and adapt like:
https://github.com/openssl/openssl/commit/51994e505dbb1cd0dd76869ec962e2948b77b585
where https://bugs.ruby-lang.org/attachments/8962 is similar
Intel docs have "The ENDBR32 and ENDBR64 (collectively ENDBRANCH) are
two new instructions that are used to mark valid indirect CALL/JMP
target locations in the program."
Change-Id: Ie867c263a888763db4478720ba189c9ec6cc974d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126859
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
How did that even pass in Jenkins on Android Arm?
Regression from commit c859b4aa48956cbf5ff41280b0008456e8f5189c
("gbuild: introduce gb_%_linktarget_target").
Change-Id: Id06cc151e92e221da856814d69eb8cced167b427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127829
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Just some refactoring.
Change-Id: I47adb93f8a413d289f6abb2a48ed3f049f582a46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127799
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I836412674448acb2a047d3d8b4711fa8d0b67257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127410
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The lock_guard moved from RTTI::GetRTTI to x86_64::getRtti to avoid recursive lock.
Change-Id: I0e71581dd57a4fb2655d4b9040fb9d943f73ab9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127095
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
This introduces two concepts: a plugin and its loader (library)
LO currrently has dependency cycles for some libraries. There is
scui, which depends on sc, while sc dlopen's scui. There are the
various vclplug_*, i18npool plugins, filters/gie, acc, etc.
Usually these plugins link to their loader library, because they
use its symbols. But as a result there is no sensible way to
express the runtime dependency of loaders on the plugins.
In GNU libtool plugins are called modules and they are implemented
in an IMHO more sensible way by allowing missing symbols at link
time. This way you can have a dependency from the loader library
to its plugins, as the plugins don't depend on the loader, but you
lose the link time detection of missing symbols.
While this is in theory possible in LO too, LO currently has
plugins, like acc (accessibility), loaded by tk (toolkit), which
depends on svt (svtools), which itself depends on tk, so dropping
the tk dependency for acc on its own doesn't help :-(
And while the dependency of the plugins on their loader is fine
for the shared / DYNLOADING build, for the "static" builds you
must (somehow) link the plugins into the executables.
I also codeified a few rules into the build system along with it:
* just plugins are allowed to depend / link other plugins
* plugins aren't allowed to be linked into the merge lib
* plugin loaders are "limited" to libraries
At the high level, this is implemented via new gbuild calls:
* gb_Library_set_plugin_for,lib,loader: declare a library to be a
plugin of a loader library and add a dependeny from the plugin
library to the loader library
* gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding
the library dependeny
* gb_Helper_register_plugins_for_install: "plugin" replacement for
gb_Helper_register_libraries_for_install to implement some
additional checks in the build system
In the end this patch just adds a bit syntactic sugar and nothing
changes for any build.
Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This partially reverts 1a5b12aa5da2c718848d3cc5d9bce7bfcdeacf54 "optimise
find/insert pattern", which caused
> ~/llvm/inst/bin/../include/c++/v1/unordered_map:1134: _LIBCPP_ASSERT '__get_const_db()->__find_c_from_i(&__p) == this' failed. unordered_map::insert(const_iterator, const value_type&) called with an iterator not referring to this unordered_map
during CustomTarget_testtools/uno_test in an experimental build with
-D_LIBCPP_DEBUG=1 on macOS.
Change-Id: Id40e5eab7c3fb1f8e1bb2599c7fb84649e870ba2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124319
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
<https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Pass-Arguments-to-Functions-Correctly>
only mentions function arguments, not return values in "The caller of a function
is responsible for signing or zero-extending any argument with fewer than
32 bits. The standard ABI expects the callee to sign or zero-extend those
arguments." But this appears to also be relevant for return values, where the
callee apparently has to provide properly extended values: Without this change,
in an --enable-optimized build, e.g. selecting "Tools - Macros - Organize Macros
- BeanShell... - LibreOffice Macros - Capitalize - capitalize.bsh" would not
enable the "Run" button, as in SvxScriptOrgDialog::CheckButtons
(cui/source/dialogs/scriptdlg.cxx) node->getType() (which returns a sal_Int16
value, and which calls DefaultBrowseNode::getType,
scripting/source/provider/BrowseNodeFactoryImpl.cxx, which in turn calls
m_xWrappedBrowseNode->getType() on a proxied Java object via the UNO bridge)
would return a value in r0 with bits > 16 left with random values, while the
calling code assumes them to be zero (and exploits that violated assumption with
--enable-optimized).
Change-Id: Ic99dd9e62b49b44e13cdde6158bef7e2296547f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123550
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|