summaryrefslogtreecommitdiff
path: root/bridges/source
AgeCommit message (Collapse)Author
2023-03-22bridges: drop unnecessary debug messageIlmari Lauhakangas
Change-Id: I4c08ea2e464164351ba66a4c04ef2575e3f5f580 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149157 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-22tdf#130924 : replace debugging printf calls with SAL_INFO/SAL_WARNYousef_Rabia
Change-Id: I94686f820e264867643bb30c83367ee702d3118d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149088 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-18tdf#130924 replace debugging fprintf calls with SAL_INFO/SAL_WARNektagoel12
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>
2023-03-18bridges: add whitespace to SAL_INFOIlmari Lauhakangas
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>
2023-03-02bridge linux x86-64 : remove useless includesArnaud Versini
Change-Id: Ibd3b9a76b700a5efbf7855454714646daf612d13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147675 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-02osl::Mutex->std::mutex in JniUnoEnvironmentDataNoel Grandin
Change-Id: Iab6d430af7afc0d21e118b05d64a15664fc2f677 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146469 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-01osl::Mutex->std::mutex in ExceptionInfosNoel Grandin
Change-Id: Ic947b58b9aba121c605b6795c7cd9aa0b16b180e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146455 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-27Remove Solaris 32-bit SPARC and x86 C++ UNO bridge implementationsStephan Bergmann
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>
2023-01-27Remove support for 32-bit S390Stephan Bergmann
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>
2023-01-27Remove support for AIXStephan Bergmann
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>
2023-01-11bridges:Fixed test fail caused by bridges on the loongarch64wjh-la
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>
2023-01-04Rudimentary support for dynamic_cast on UNO proxy objectsStephan Bergmann
<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>
2023-01-04Fix Itanium vtable constructionStephan Bergmann
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>
2022-11-10Add riscv64 supportSakura286
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
2022-10-11Deduplicate O(U)StringConcatenationMike Kaganski
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>
2022-09-07Fix register clobber information and simplify in the C++/UNO bridge for iOSTor Lillqvist
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>
2022-08-22cid#1500671 silence Resource leakCaolán McNamara
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>
2022-08-22cid#1500470 silence Resource leakCaolán McNamara
Change-Id: I846746a351c619a4de7abce7a6443f510dc41690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138661 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-17cid#1500585 Dereference before null checkCaolán McNamara
Change-Id: I9374a580d3dce7c7851881ff8193946d46ed2bec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138384 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-13bridges/jni : remove useless using and use css instead of com::sun::starArnaud VERSINI
Change-Id: I1b73d68b007ba0dfa54f99ff8f8fea55e94a1ed2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137651 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-11Add loongarch64 support.wjh-la
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>
2022-08-10Better cast to sal_[u]IntPtr when passing pointer to O[U]String::numberStephan Bergmann
Change-Id: I5b7a0fa060c1e0ae4aa194e0c1862f303dd8a2d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138062 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-07-10tdf#143148 Use pragma once instead of include guardsam.faraji
Change-Id: I7bd02dba44a8bc62da660bcb7500960ef14172a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136939 Tested-by: Hossein <hossein@libreoffice.org> Reviewed-by: Hossein <hossein@libreoffice.org>
2022-06-21elide some makeStringAndClear() callsNoel Grandin
Change-Id: Ie8c04a8c414f32cc0e68fbab1d24a9707f179011 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136201 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-21clang-tidy modernize-pass-by-value in bridgesNoel Grandin
Change-Id: I6c52316e46117aacb22a2adcb75841aed834041f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134705 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-05use more o3tl::getTokenNoel Grandin
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>
2022-04-25loplugin:stringviewStephan Bergmann
Change-Id: I4bd3efe67217a4c4418cf308cc8e7a55cf4a604a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133390 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-22use more string_view in bridgesNoel Grandin
Change-Id: I842668655dec102e1595dcbac6413fe2b49d8515 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133268 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-25bridges : use std::mutex in java brigeArnaud Versini
Change-Id: I07b215067b1cefc87919680fad3299d702ff6d1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132100 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-08Drop some debug codeStephan Bergmann
...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>
2022-03-05tdf#130924 replace debugging printf calls with SAL_INFO/SAL_WARNpragat-pandya
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>
2022-03-03Avoid loplugin:noexceptStephan Bergmann
...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>
2022-01-19WASM UNO: add a minimal dummy bridgeThorsten Behrens
... 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>
2022-01-15Let loplugin:nullptr look into template instantiationsStephan Bergmann
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>
2022-01-06annocheck warning about missing .note.gnu.property sectionCaolán McNamara
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>
2021-12-24bridges : remove redundant publicArnaud VERSINI
Change-Id: I836412674448acb2a047d3d8b4711fa8d0b67257 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127410 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-20bridges : use std mutex instead of osl::Mutex.Arnaud VERSINI
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
2021-10-28Revert broken optimization attemptStephan Bergmann
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
2021-10-13Extend return values < 32-bit on macOS ARM64Stephan Bergmann
<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>
2021-10-11In O[U]StringBuffer, make string_view params replacements for OUString onesStephan Bergmann
...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>
2021-09-06tdf#130924 : replace debugging printf calls with SAL_INFO/SAL_WARNEmircan Agac
Change-Id: Ifede38f3b19d1e5226e18dba1aa21d478a430d9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120763 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-08-22WaE: protect clang diagnostic push/pop with if defined __clang__Caolán McNamara
Change-Id: I8360aa96097a13b6bad1283edddc7c2fd1ed510d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120832 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-21arm: fix bridgeCaolán McNamara
which went a little wrong in commit dd91d3389c26645459d3b80649941d65efa4f63f Date: Sat Jan 2 14:36:44 2021 +0100 Fix some warnings for Raspberry pi 4 (part3) Change-Id: Ief7e1146b7480a1c16ec0810f991296710214332 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120830 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-21arm: nStackBytes was already the right amount of bytesCaolán McNamara
possible regression from... commit 6e3424ca1131fe371f63e456267de476b5eb0eae Date: Sat Jan 2 11:03:12 2021 +0100 Fix some warnings for Raspberry pi 4 (part2) which changed that Change-Id: I9a19d7d6bc1e4115ffffbe32d8d62be5d275d500 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120747 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-17rtl::Static -> thread-safe static localNoel Grandin
Change-Id: I9f8fe250813f4f376dc46c6f3d7e25e90fdbb50e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120566 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-03Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-02tdf#143450: Special integre+fp struct return case needs a fix too, of courseStephan Bergmann
...similar to ca344be7aabf88dddde38841e6af6292ece6829b "tdf#143450: Fix special fp+integer struct return case for gcc_*_x86-64" Change-Id: Ia8110d632a1c5f328822c434efc5b09bd53ec9e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119883 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-30cid#1489551 silence Uninitialized scalar variableCaolán McNamara
and cid#1489552 Uninitialized scalar variable Change-Id: I056cfd95d34f2163e68b83cce21bce70ccf5fc8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119701 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-28Annotate the .eh_frame dataStephan Bergmann
...to convince myself that it is only about the initial %rsp/%rbp fiddling, and is not affected by the ca344be7aabf88dddde38841e6af6292ece6829b "tdf#143450: Fix special fp+integer struct return case for gcc_*_x86-64" changes to later parts of privateSnippetExecutor Change-Id: I7bfad4cb5e1c2208e29c73a70874b6e9eff29eb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119610 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-28tdf#143450: Fix special fp+integer struct return case for gcc_*_x86-64Stephan Bergmann
For one, the loop in x86_64::fill_struct was backwards. And for another, privateSnippedExecutor does not need special handling of FLOAT and DOUBLE return values (they can simply be moved to %xmm0, as covered by the general case), but rather for those small structs where floating-point member(s) in a first eightbyte (targeting %xmm0) are followed by integer member(s) in a second eightbyte (targeting %rax). Extended testtools to cover two such cases. Change-Id: I8e775a1d1ce2312610f265bcc8e40b09bdac56df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119576 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>