summaryrefslogtreecommitdiff
path: root/bridges
AgeCommit message (Collapse)Author
2020-01-26remove some unused local varsNoel Grandin
found by a more aggressive variant of loplugin:unusedvariables. This is my first pass, committing the simplest and most obviously unnecessary vars Change-Id: I9676a6e39a101937097788548764506c93811c57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87414 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-14clang-tidy modernize-concat-nested-namespace in basic..canvasNoel Grandin
Change-Id: I74a575e6ca7829ee252c0e315fc337ea223c944f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86758 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-07aarch64 r18 is reserved at least on AndroidStephan Bergmann
<https://github.com/ARM-software/software-standards/blob/master/abi/aapcs64/ aapcs64.rst> states: "The role of register r18 is platform specific. If a platform ABI has need of a dedicated general purpose register to carry inter- procedural state (for example, the thread context) then it should use this register for that purpose. If the platform ABI has no such requirements, then it should use r18 as an additional temporary register." For a --host=aarch64-linux-android build, Clang warned > bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:39:9: error: inline asm clobber list contains reserved registers: X18 [-Werror,-Winline-asm] > "ldp x0, x1, [%[gpr_]]\n\t" > ^ > <inline asm>:1:1: note: instantiated into assembly here > ldp x0, x1, [x20] > ^ > bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:39:9: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour. > "ldp x0, x1, [%[gpr_]]\n\t" > ^ > <inline asm>:1:1: note: instantiated into assembly here > ldp x0, x1, [x20] > ^ and <https://github.com/llvm/llvm-project/commit/ 9c9c8b22d2ea150cc889232871b0c8303d3644d9> "Start reserving x18 by default on Android targets" shows that at least LLVM/Clang claims that the Android ABI reserves it (though it doesn't cite any sources for that). (If this bridges/source/cpp_uno/ implementation is used for other non-Linux OS like Fuchsia, we may need to extend the #if accordingly; see the above LLVM commit for which platforms it claims reserve the register.) Change-Id: I62a5210ddc4784eee2ab56ee134b9e195827b9dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Silence -Werror,-WuninitializedStephan Bergmann
...as seen with "Android (5220042 based on r346389c) clang version 8.0.7 (https://android.googlesource.com/toolchain/clang b55f2d4ebfd35bf643d27dbca1bb228957008617) (https://android.googlesource.com/toolchain/llvm 3c393fe7a7e13b0fba4ac75a01aa683d7a5b11cd) (based on LLVM 8.0.7svn)", warning about functionIndex, vtableOffset, and indirectRet being used "uninitialized" (but which is as intended, carrying over the values those registers have upon entry to the function) Change-Id: I443fe2e8bf7c25a5bd2bfd99c245d430be65f445 Reviewed-on: https://gerrit.libreoffice.org/85400 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18tdf#128671: Rely on unwind.h, declare what's missing from cxxabi.hStephan Bergmann
...for gcc3_linux_aarch64, similar to what 128deeae81a6f802bfb79b8f0fa8c4b10729f7db "cxxabi.h is not specific to GCC" et al did for gcc3_linux_x86-64 Change-Id: Iee9980842c0e5f6f49642407339a67e865f8be9c Reviewed-on: https://gerrit.libreoffice.org/85344 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Fix typos concerning the __cxa_exception checkStephan Bergmann
...introduced with 069506bcb0ee4005b01c22095ed427b96b553c98 "Use config_cxxabi.h to check for __cxa_eh_globals, __cxa_exception", but which appear to have been harmless as (a) the checked-for __cxxabiv1::__cxa_exceptions never existed in cxxabi.h, and (b) lack of __cxxabiv1::__cxa_exception in cxxabi.h happened to conincide with !HAVE_CXXABI_H_CXA_EH_GLOBALS Change-Id: I13f8a2b3cf0f03f2bc96cf053d2b571860055978 Reviewed-on: https://gerrit.libreoffice.org/85373 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Elide use of rtl_Instance (which is obsoleted by C++11 thread-safe statics),Stephan Bergmann
...redux, after 8473ac2e27efff3ec902a358896a669ce05f047a "Elide use of rtl_Instance (which is obsoleted by C++11 thread-safe statics)" had done the same in parallel but forgot to remove some now-unnecessary parts: There appears to be no good reason to control the lifecycle of the VtableFactory instance via dso_init/exit, instead of via a plain static local variable. This removes the need for the Windows DllMain functions. They also called DisableThreadLibraryCalls, which disables the DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications for the respective DllMain. Lets assume that this was only done (as an optimization) because there had to be a user-provided DllMain, and that it was not in itself a reason to have a user-provided DllMain. (Most other DllMain across the code base that call DisableThreadLibraryCalls also do something else. The only DllMain that only calls DisableThreadLibraryCalls is the one in shell/source/win32/shlxthandler/ooofilt/ooofilt.cxx, introduced with 3fbfb21e298ba506c50733d4aaefc7550bca2fe4 "INTEGRATION: CWS desktintgr02".) Change-Id: I696e1c8d49060853c1a2c24f67469f6adfea6801 Reviewed-on: https://gerrit.libreoffice.org/85367 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18Elide use of rtl_Instance (which is obsoleted by C++11 thread-safe statics)Noel Grandin
which does not seem to have been doing anything useful here anyway, not since commit 730399de90add4e35da9754a8f7525b443237026 Date: Wed Jul 18 11:16:06 2007 +0000 INTEGRATION: CWS unomacli64 (1.6.50); FILE MERGED 2007/06/20 10:29:46 kr 1.6.50.1: fixed: #i78284# Change-Id: I57345a08c333953a66b3a5f3be1fe9a2f1f092ef Reviewed-on: https://gerrit.libreoffice.org/85328 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-10loplugin:unusedmember (clang-cl)Stephan Bergmann
(The struct that is the type of EHExceptionRecord::params does not need a name.) Change-Id: I372630563dce26c3ac190a9492eabfad9a55a943 Reviewed-on: https://gerrit.libreoffice.org/84861 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-06loplugin:external (macOS)Stephan Bergmann
* OldEntry in fpicker/source/aqua/resourceprovider.mm was apparently unused ever since it got introduced with 00657aef09d854c74fb426a935a3e8b1fc390bb0 "migrate to boost::gettext" * impl_throwError is used from multiple TU, connectivity/source/drivers/macab/MacabStatement.cxx just missed the relevant #include Change-Id: Iba131da57aa20085bb1c634ba9a3a59566070abd Reviewed-on: https://gerrit.libreoffice.org/84653 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05loplugin:external (clang-cl)Stephan Bergmann
...plus loplugin:consttobool and loplugin:fakebool fallout Change-Id: Ie3d8121815c080b13bea6d9deca1eb138ca56138 Reviewed-on: https://gerrit.libreoffice.org/84515 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05android: Avoid throwing exceptions through the bridges.Jan Holesovsky
From some reason it does not work, so let's do the same we are doing on iOS; at least for now. Change-Id: I915f8683a112548fc3defc1114f9dce3aa7be30e Reviewed-on: https://gerrit.libreoffice.org/84067 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/84204 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2019-12-02bridges arm64: Use [[falltrough]].Jan Holesovsky
Change-Id: I28d3cabab74bea6ea9f2712c240110a44643c54d Reviewed-on: https://gerrit.libreoffice.org/84193 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-19loplugin:fakebool (clang-cl)Stephan Bergmann
...plus follow-up loplugin:implicitboolconversion and loplugin:redundantcast Change-Id: I9fc9c5cb46fbb50da87ff80af64cb0dfda3e5f90 Reviewed-on: https://gerrit.libreoffice.org/83207 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-17Extend loplugin:external to warn about enumsStephan Bergmann
To mitigate the dangers of silently breaking ADL when moving enums into unnamed namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79 "New loplugin:external"), note all functions that are affected. (The plan is to extend loplugin:external further to also warn about classes and class templates, and the code to identify affected functions already takes that into account, so some parts of that code are not actually relevant for enums.) But it appears that none of the functions that are actually affected by the changes in this commit relied on being found through ADL, so no adaptions were necessary for them. (clang::DeclContext::collectAllContexts is non-const, which recursively means that External's Visit... functions must take non-const Decl*. Which required compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support such Visit... functions with non-const Decl* parameters.) Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd Reviewed-on: https://gerrit.libreoffice.org/83001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-06loplugin:indentation find broken if statementsNoel Grandin
so I don't read the "then" block as being a sequential statements Change-Id: Ib2004acd3518bd4ebd2246f02a26c2c0a8bbab4c Reviewed-on: https://gerrit.libreoffice.org/82069 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-05typeinfo fix for x86Tomoyuki Kubota
Change-Id: Ic0a9dcb97cfda4155f33d9ad07a96db8960b57a0 Reviewed-on: https://gerrit.libreoffice.org/82023 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-17Remove some memset callsMike Kaganski
Replace them with default initialization or calloc Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1 Reviewed-on: https://gerrit.libreoffice.org/80805 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-16loplugin:bufferadd loosen some constraintsNoel Grandin
and extend O*StringView to have a constructor that takes a pointer and a length Change-Id: I6120e96280f030757e855a6596efdae438b7e1e8 Reviewed-on: https://gerrit.libreoffice.org/80872 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-12aarch64 callVirtualFunction needs to be compiled w/o -fstack-clash-protectionStephan Bergmann
At least when doing an aarch64 Flatpak build against org.freedesktop.Sdk//19.08, which uses GCC 9.2.0 and passes in `CXXFLAGS=-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection`, callVirtualMethod (in bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx) would decrement the stack pointer another 16 bytes after the stackargs = alloca(...); and before the asm block, so in the called virtual function, arguments read from the stack would read garbage (and CustomTarget_testtools/uno_test would fail with SIGSEGV at > #0 0x0000ffffb733eb48 in rtl::OUString::operator= (this=0xaaaaf9c1ac30, str=...) at /run/build/libreoffice/include/rtl/ustring.hxx:453 > #1 0x0000ffffb733a7bc in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:99 > #2 0x0000ffffb733a87c in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:115 > #3 0x0000ffffb733ade4 in bridge_object::Test_Impl::setValues (this=0xaaaaf9c1abb0, bBool=1 '\001', cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=..., rStruct=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:548 > #4 0x0000ffffb740bff4 in callVirtualFunction (function=281473755360772, gpr=0xffffd1ab1f28, fpr=0xffffd1ab1f68, stack=0xffffd1ab1d40, sp=8, ret=0xffffd1ab22c0) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:63 > #5 0x0000ffffb740ca70 in (anonymous namespace)::call (proxy=0xaaaaf9c291c0, slot=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, returnValue=0xffffd1ab22c0, arguments=0xffffd1ab2230, exception=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:178 > #6 0x0000ffffb740d4c4 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0xaaaaf9c291c0, pMemberDescr=0xaaaaf9c55950, pReturn=0xffffd1ab22c0, pArgs=0xffffd1ab2230, ppException=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:361 > #7 0x0000ffffb740720c in (anonymous namespace)::call (proxy=0xaaaaf9c549c0, description=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:120 > #8 0x0000ffffb74079a0 in (anonymous namespace)::vtableCall (functionIndex=40, vtableOffset=0, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:291 > #9 0x0000ffffb7407b00 in (anonymous namespace)::vtableSlotCall (gpr0=187651311618536, gpr1=1, gpr2=64, gpr3=17, gpr4=4660, gpr5=65244, gpr6=305419896, gpr7=4275878552, fpr0=5.4321266044931319e-315, fpr1=3.1415926358999999, fpr2=0, fpr3=4.0039072046065485, fpr4=0, fpr5=4.003911019303815, fpr6=8.9589789687541617e+102, fpr7=-4.4588500238274385e-308) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:348 > #10 0x0000ffffb739e60c in bridge_test::performTest (xContext=..., xLBT=..., noCurrentContext=false) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:378 > #11 0x0000ffffb73a3d58 in bridge_test::TestBridgeImpl::run (this=0xaaaaf9c18550, rArgs=...) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1162 > #12 0x0000aaaad292a3ec in sal_main () at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:509 > #13 0x0000aaaad29297a0 in main (argc=8, argv=0xffffd1ab31b8) at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:349 .) By experiment, I found the problematic thing to be -fstack-clash-protection, which can apparently be cancelled with a subsequent -fno-stack-clash-protection at least on that GCC 9.2.0. (And -f[no-]stack-clash-protection appears to only be available since GCC 8, and not at all for Clang, so check for it with HAVE_GCC_STACK_CLASH_PROTECTION.) Change-Id: If667fdf704b1ba20a04593b38d2d1f079280df41 Reviewed-on: https://gerrit.libreoffice.org/80701 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-04always use gb_LinkTarget__get_cxxflags for cxxobjectsLuboš Luňák
E.g. gb_LinkTarget_add_exception_object adds it explicitly, but gb_LinkTarget_add_cxxobject itself does not, even though other variants (c,objc,objcxx) do it. This means that when compiling tools/qa/cppunit/test_cpuid.cxx it doesn't get the correct -O/-g flags, because CppunitTest_tools_test.mk uses gb_CppunitTest_add_cxxobjects to add $(INTRINSICS_CXXFLAGS). And that in its own actually should use the add_exception_objects variant, it didn't presumably because that one used to have cxxflags passing broken until I fixed it in 4bbdab901eb3c7d32d28910fb830f4b0422eee91. The usage in Library_cpp_uno.mk even explicitly works around the lack of debug symbols. Change-Id: Idc794e95bb817cd2ba2942b8e1f04f80d6722f97 Reviewed-on: https://gerrit.libreoffice.org/80119 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-24latest update of Visual Studio complains about typeinfo.hTomoyuki Kubota
Change-Id: If8643ddd823ec1c970a7211be1547853162659a0 Reviewed-on: https://gerrit.libreoffice.org/79461 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-23android: add support for 64bit buildChristian Lohmaier
Change-Id: Id8aae84308f6128351ae2f93c8fbc8941a0c7fc6 Reviewed-on: https://gerrit.libreoffice.org/79085 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2019-09-19improve and enable loplugin:fragiledestructorNoel Grandin
Where the problem was benign and the class was not extended, I marked the class as final. Where the problem was benign and the class was extended, I marked the relevant callee methods as final. Other cases were excluded in the plugin. Change-Id: Idb762fb2206af4e8b534aa35ff77f8368c7909bc Reviewed-on: https://gerrit.libreoffice.org/79089 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-05loplugin:useuniqueptr in VtableFactoryNoel Grandin
Change-Id: I122b6749f148abb48f646bfcd32ef86e2f5fa553 Reviewed-on: https://gerrit.libreoffice.org/78651 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-21loplugin:constvars, look for loop vars that can be constNoel Grandin
Change-Id: I67ee714739800f3718f9d3facf57474cd564d855 Reviewed-on: https://gerrit.libreoffice.org/77415 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-18Fix typosAndrea Gelmini
It passed "make check" on Linux Change-Id: Ibda74a6c5bd50bac7af3b3af1f294817c3e406cc Reviewed-on: https://gerrit.libreoffice.org/77667 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-08-08android: support NDK 19 and above (20 as of this commit)Christian Lohmaier
support for targeting API 14 and 15 was removed in NDK 18, so set minimum version to 16 mips support was removed in NDK 17 Clang now takes care about correct linking with libc++ shared or static, so don't manually specify them anymore. Same with __ANDROID_API_LEVEL__ define and the sysroot / isystem handling, that is all covered by a single -target <triple><version> simplifying things quite a bit. also align ownloud sdk values with main build.gradle Change-Id: Ib3ae4484e52214677e826270b731ecf7c5c15445 Reviewed-on: https://gerrit.libreoffice.org/77104 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2019-05-31Replace 0 in nullptrJuergen Funk
Change-Id: I517a036ccf41c377fee78f841f474b72998bd9ac Reviewed-on: https://gerrit.libreoffice.org/73028 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-05-10an uno -> a unoCaolán McNamara
Change-Id: I538db88f8477dd2d2ad25c372928fec6c11d979d Reviewed-on: https://gerrit.libreoffice.org/72105 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-05-05Fix remaining uses of gb_SYMBOLStephan Bergmann
...after eeeec33ada5923f1f534334b22c15d6e2c6f1d35 "merge --enable-selective-debuginfo into --enable-symbols" had removed it Change-Id: I83aed6e21c4b983d8645707daa65bd85ec16ff6b Reviewed-on: https://gerrit.libreoffice.org/71798 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-04-19optimise find/insert patternNoel Grandin
if we're doing a find/insert on a set or a map, it is better to just do a conditional insert/emplace operation than triggering two lookups. Change-Id: I80da5097f5a89fe30fa348ce5b6e747c34287a8d Reviewed-on: https://gerrit.libreoffice.org/70937 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-13use more std::make_uniqueNoel Grandin
Change-Id: I7d85cbc9105c5e0c4a8d9a69c4ac9d6dfc07eabd Reviewed-on: https://gerrit.libreoffice.org/70663 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-03Revert "add more append methods to *StringBuffer"Noel Grandin
This reverts commit 8cfa7f4dc00f3dd37e57917ef25c806b0e9e6e73. comment from sberg: we already have 70519a43e0d89a6b5d89859a6851f8c757c6b0c7 "Replace OUStringBuffer::appendCopy with append(std::u16string_view)" (which can be extended to OStringBuffer if needed) Change-Id: Ifcc550a8cf26ef38ad49fde8b067f53c999c9276 Reviewed-on: https://gerrit.libreoffice.org/70178 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-03add more append methods to *StringBufferNoel Grandin
which performs the append without needing the creation of a temporary *String Change-Id: If9ad3222275f26659db2e7df8d34f068977c4d17 Reviewed-on: https://gerrit.libreoffice.org/69826 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-03-27loplugin:typedefparam (clang-cl)Stephan Bergmann
Change-Id: I07604028845c49cc084927e21db7f21c5d053bab Reviewed-on: https://gerrit.libreoffice.org/69796 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-16Simplify containers iterations in basctl, basegfx, basic, bridgesArkadiy Illarionov
Use range-based loop or replace with STL functions Change-Id: I8594740103bdc2091c2d03d4b92bbe8393f5378c Reviewed-on: https://gerrit.libreoffice.org/69223 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-22tdf#112689: Replace changed O(U)StringBuffer::append() with operator+Omer Fatih Celik
Change-Id: Ief3f2554bf2271dbfa60ff9fbc04e3c5d3540f68 Reviewed-on: https://gerrit.libreoffice.org/68146 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-02-21loplugin:indentation (macOS)Stephan Bergmann
* Some .m/.mm files that still contained tabs instead of spaces have been cleaned up with Emacs' untabify (and apple_remote/source/HIDRemoteControlDevice.m needed further manual adaptions): apple_remote/source/GlobalKeyboardDevice.m apple_remote/source/HIDRemoteControlDevice.m apple_remote/source/KeyspanFrontRowControl.m apple_remote/source/RemoteControl.m vcl/osx/a11yrolehelper.mm * Some of the changes predate 0626e66d761de18f62e4d00d427903032da9d517 "Avoid loplugin:indentation after preproc conditional inclusion lines" and would likely have no longer been flagged since. Change-Id: Ibf5faffa743c7f79b36109d9879eb79d63c8c40f Reviewed-on: https://gerrit.libreoffice.org/68090 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-19tdf#112689:Replace chained O(U)StringBuffer::append() with operator+Salih Sariyar
Change-Id: I4c9fc9595a498609309ce7734c312fea09680c2f Reviewed-on: https://gerrit.libreoffice.org/67586 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-02-11Revert "tdf#112689: Replace changed O(U)StringBuffer::append() with operator+"Tor Lillqvist
Sorry, but this change breaks the build: bridges/source/cpp_uno/msvc_win32_x86-64/except.cxx(884): error C2110: '+': cannot add two pointers This reverts commit 867384792244667a33cad79a7348b34b6008822b.
2019-02-11tdf#112689: Replace changed O(U)StringBuffer::append() with operator+Omer Fatih Celik
Change-Id: I9221608db417217dd7c97c0300ecedb67fa74132 Reviewed-on: https://gerrit.libreoffice.org/67603 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-08The gcc3_linux_aarch64 bridge needs to call __cxa_current_exception_type, tooStephan Bergmann
...or else mapException would extract garbage from the fake exception->exceptionType std::type_info* when catching via cppu::getCaughtException the rethrown exception thrown via std::rethrow_exception in Test::testgetCaughtException in cppuhelper/qa/misc/test_misc.cxx. 6ddecf61ecada646fbd6f8809270d47289727e8a "fillUnoException not working on std::rethrow_exception exceptions" had adapted the other relevant bridges/source/cpp_uno/gcc3_*/ cases but missed the gcc3_linux_aarch64 one. Change-Id: I5a2afb11ad4abf851169bd3fd8ae647cc81c2fcd Reviewed-on: https://gerrit.libreoffice.org/67542 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-08loplugin:indentation in basctl..bridgesNoel Grandin
Change-Id: Ie4e27466c4258c6f774a3ebb82ec3a88c28fd753 Reviewed-on: https://gerrit.libreoffice.org/67525 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-30loplugin:redundantinline (clang-cl)Stephan Bergmann
Change-Id: Ib6320ddc049e93cca4c5931ad28d1873d34bd8b4 Reviewed-on: https://gerrit.libreoffice.org/67137 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-16o3tl::make_unique -> std::make_unique in basctl...bridgesGabor Kelemen
Since it is now possible to use C++14, it's time to replace the temporary solution with the standard one Change-Id: I9a20a58c68d12656359dcaa060d8ab41f621af32 Reviewed-on: https://gerrit.libreoffice.org/66262 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-20Fix typoAndrea Gelmini
Change-Id: I95c7fd5a7241c120395c897af4fc2742528e2166 Reviewed-on: https://gerrit.libreoffice.org/65391 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-12-13Add missing "!"Stephan Bergmann
Change-Id: Ic3e50e1a64b334bee86db7456a4821fa9427370b
2018-12-13Fix getRTTI for Android x86Stephan Bergmann
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 312eeeee42cb4a1e356943e17305555e41afc4ef "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>
generated by cgit (git 2.34.1) at 2024-12-29 03:19:56 +0000