config_host_lang.mk.in - lo/core - LibreOffice 核心代码仓库

index : lo/core

LibreOffice 核心代码仓库

文档基金会

summary refs log tree commit diff

path: root/config_host_lang.mk.in

blob: dbd641499599ad3ac4a90adf6b3ee47f39993eae (plain)

 # language-related config variables for LibreOffice
 # this file is intended to be able to be included in a Makefile
 # and not to be sourced in a shell session
 #

export ALL_LANGS=@ALL_LANGS@
export WITH_LANG=@WITH_LANG@
export WITH_LANG_LIST=@WITH_LANG_LIST@

30 20:03:41 +0000'>2023-03-30loplugin:stringadd in variousNoel Grandin when applying my upcoming patch to also consider O[U]StringBuffer Change-Id: I8cf6a47ad357ddc73e2c430d966be72d5efd1485 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149767 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-10-18tdf#151545: Restrict JvmfwkUtil_isLoadableJVM to macOS x86-64Stephan Bergmann That check had been added with 32bc8ddbf335dd26019edcf12758643b4cff9913 "tdf#94716 allow Oracle's JDK to be used on OS X 10.10 and 10.11", back at a time when there was substantial trouble with installations of Apple's own Java and Oracle JREs. One consequence of that commit and its JvmfwkUtil_isLoadableJVM check was that on macOS we only supported JDKs (with a surrounding Contents directory containing an appropriate Info.plist files), not plain JREs (cf. <https://wiki.documentfoundation.org/ReleaseNotes/5.1#macOS> "Prior work arounds of having both an Apple JRE 6 and an Oracle JRE 8 are no longer sufficient. Use of the JDK is now hard coded, see tdf#74877, tdf#94716 and core commit 32bc8ddbf335dd26019edcf12758643b4cff9913.") However, Apple's own Java is long since deprecated (cf. <https://support.apple.com/en-us/HT204036> "You can also download legacy Java SE 6 from Apple if you’re using an app that specifically requires this unsupported, out-of-date version."), and presumably of no practical concern at least on contemporary Aarch64-based macOS. And there is e.g. SDKMAN! (<https://sdkman.io/>), which installs JDKs in a way that they are not surrounded by Contents directories containing appropriate Info.plist files, so JvmfwkUtil_isLoadableJVM returned false for them and you couldn't add them on the LibreOffice Advanced Options tab. So at least for Aarch64-based macOS, drop that presumably-legacy JvmfwkUtil_isLoadableJVM check (but keep it for x86-64--based macOS at least for now, just to be safe). (That implies that for Aarch64-based macOS, it should now work again to also use plain JREs.) Change-Id: I3bcbb3c14e3a9e9dde39fd6f4572b632e05df9e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141508 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-09-23Fix a misuse of two-argument std string_view rfindStephan Bergmann ...introduced in 655b6c2f46a73d9893ba8e6b572731a5890a4f72 "loplugin:stringviewparam". Unlike its O[U]String lastIndexOf(x, n) counterpart (which looks for the last x whose end position, exclusive, is <= n), string_view rfind(x, n) looks for the last x whose start position, inclusive, is <= n. (So here would have left slash unchanged.) (And the seemingly simpler jvm_dll.rfind('\\', slash - 1) would fail when slash is zero, as in that case it would call rfind with a second argument of npos, i.e., search for the last '\\' in the complete jvm_dll.) Change-Id: I148a5db860d4b9e9d58a4a8847880a7a7020c5a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140486 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-06-21clang-tidy modernize-pass-by-value in io..jvmfwkNoel Grandin Change-Id: I6e19d4d03957c35caa79a231927eae04ae630442 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136209 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-04-10loplugin:stringviewparamStephan Bergmann Change-Id: I62a7534844006a7bf3c2ece5e5d2f8b739a15b9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132762 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-02-22Replace some fprintf with SAL_WARNStephan Bergmann Change-Id: I3f31f223b6e906c6b40415a8d5c66c27e3c7cff5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130338 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-02-22Remove a debug-style fprintfStephan Bergmann ...that had been added in 811de66d7fd8c93c43d8e4e2dc73720033ba939b "First attempt at getting access to the Java VM on Android", together with another fprintf(stderr, "Got lo_get_javavm = %p", lo_get_javavm); that had meanwhile been removed again in 5510127e89d6971a219ce3664e4631d6c6dda2b1 "Android code refactorig and hacking" Change-Id: I1a50563e2af1ea5a0ecbd2cc9d49d70c6e5bbbd3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130337 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Jenkins 2022-02-21Avoid unnecessary empty -Djava.class.path=Stephan Bergmann Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2021-11-16rtl::Static->thread-safe static in jvmfwkNoel Grandin Change-Id: I049148d82eb306e8ba7fdc9f0cc650f45b05da0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125257 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-10-21Make getVersionInformation always return a VersionInfoStephan Bergmann ...even for JREs not listed in javavendors.xml, making it default to a VersionInfo with sMinVersion = "1.8.0". 3d27b2fa9c5a03f78e5145377402f8a88e3da1be "tdf#124503: Support JRE installations with unknown java.vendor property", which had changed getVersionInformation to return an optional<VersionInfo>, said in the commit message: "For simplicity, assume that any versions of such JREs are supported. Our baseline is Java 6, and there are unlikely any older versions of JREs from unknown vendors out there." Our baseline is Java 8 by now, and there are still unlikely any older JREs out there, but for macOS ARM64 we may want to restrict to at least Java 17 implementing <http://openjdk.java.net/jeps/391> "JEP 391: macOS/AArch64 Port", and this commit is a prerequisite for such a change (where we would then e.g. change the hardcoded "1.8.0" to "17" for just that one platform). (OtherInfo::compareVersions in jvmfwk/plugins/sunmajor/pluginlib/otherjre.cxx unconditionally returns 0, meaning "versions compare equal", so introducing a default version of "1.8.0" should have no negative effect on any JREs that use OtherInfo.) Change-Id: I34dc5f2b755c2254a91d42c262786ceec70c746e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123958 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2021-10-05drop 'using namespace std' in h* i* j*Julien Nabet Change-Id: I3c28651779f17e1a410505ffaa863b4773037ccf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123119 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2021-01-02Fix some warnings for Raspberry pi 4 (part2)Julien Nabet Fix these kinds: /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:103:10: error: externally available entity 'is_complex_struct' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] bool is_complex_struct(const typelib_TypeDescription * type) ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:129:10: error: externally available entity 'is_float_only_struct' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] bool is_float_only_struct(const typelib_TypeDescription * type) ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:168:6: error: externally available entity 'MapReturn' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] void MapReturn(sal_uInt32 r0, sal_uInt32 r1, typelib_TypeDescriptionReference * pReturnType, sal_uInt32* pRegisterReturn) /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:446:32: error: static_cast from 'void **' to 'sal_Int32 *' (aka 'long *') is not allowed sal_Int32 * pTempIndices = static_cast<sal_Int32 *>(pCppArgs + nParams); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ or some of these: In file included from /home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26: /usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1945:1: error: unknown attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes] _JNI_IMPORT_OR_EXPORT_ jint JNICALL ^ /usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded from macro '_JNI_IMPORT_OR_EXPORT_' define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT ^ /usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note: expanded from macro 'JNIIMPORT' define JNIIMPORT __attribute__((externally_visible,visibility("default"))) Change-Id: I7cae1c52ee10306da666c9c234b9af7248efd04e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108567 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann ...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-11-30loplugin:stringviewparam include comparisons with string literalsNoel Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-11-25loplugin:stringview (clang-cl)Stephan Bergmann Change-Id: I47b44c80b2a5e3c9d84f5d7257efe17f138a1067 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106563 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann ...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-08-18Add missing punctuation/spaces to error messagesStephan Bergmann Change-Id: I4be46342b24a5993df74dbd047d88842a8df0412 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100901 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-05-19Avoid UB when calling setjmpStephan Bergmann The C standard (and thus by reference also the C++ standard) has very picky constraints how invocations of the setjmp macro need to appear to not cause undefined behavior. Change-Id: I09418de340a044e4309261bae9816ca746700858 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94474 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-05-17jvmfwk: fix [-Werror,-Wunused-function]Thorsten Behrens After recent cleanups, android build fails with sunjavaplugin.cxx:204:5: error: unused function 'createJvm' [-Werror,-Wunused-function] Change-Id: Idc9a97673debdd5da798fbdc729b8d90b6b7af9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94371 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> 2020-05-15Drop the JVM "feature" concept supportStephan Bergmann ...now that 6ba74150866d71469827de9f4f19268dfa7db137 "jfw::isAccessibilitySupportDesired is obsolete" demonstrated that there is no more need for JFW_FEATURE_ACCESSBRIDGE, the sole feature that had been provided. * The javasettings_*.xml format still supports the <feature> tag, but it is ignored when reading and always written as "0". * There is no trace that "the bootstrap parameter JFW_PLUGIN_NO_NOT_CHECK_ACCESSIBILITY" whose mention gets removed from jvmfwk/plugins/sunmajor/pluginlib/JREProperties.java had ever been supported. (The only mention was 6873b3be47d71f94c38262003101576081acd241 "INTEGRATION: CWS jre5issues (1.3.18); FILE MERGED: 2005/01/18 12:48:48 jl 1.3.18.1: #i40879# in build environment the JRE is not tested for accessibility, because of potential X server problems" introducing that comment.) * The "Features" column is removed from the JRE table on the "LibreOffice - Advance" options page. Change-Id: I332d34b60548e7f2f852241ea8edfbee0ffcf510 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94329 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-05-15Avoid any false GCC -WclobberedStephan Bergmann ...by moving the code that calls JNI_CreateJavaVM and the setjmp that it may longjmp to (from abort_handler that may be called from within JNI_CreateJavaVM) into its own small function. That way, no local variables in jfw_plugin_startJavaVirtualMachine should produce any such false "variable might be clobbered by ‘longjmp’ or ‘vfork’" GCC warnings any longer, and all the workarounds to silence such warnings can be removed. Change-Id: I6de134628e8efbf2d67fcd83a9cc2623b55762a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94330 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-05-15Use symbolic JFW_FEATURE_ACCESSBRIDGEStephan Bergmann (unclear why 43cc8abfb0a41878c4e78fd3b868b1d4f344c610 "#i20052# plugin lib for java framework" hadn't done so from the start, when 2b24c46035657a8a43c6552328f7b4dda1622ce5 "#i20052# java framework" had already introduced the macro) Change-Id: I7f83e5ee68300438bcf7b49bdd12512ca0cbea42 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94286 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-05-13The -Wclobbered hack appears to be needed for all versions of GCCStephan Bergmann What apparently triggers it here is a combination of --enable-assert-always-abort --enable-optimized --enable-werror See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103> "Unexpected -Wclobbered in bits/vector.tcc with -O2" for a stripped-down reproducer. Change-Id: Ic2cff0e402290cd9fd67790168dc1183799e3f14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94121 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-05-13gcc 10 also generates this clobber warningNoel Grandin (specifically 10.1.1 is the version I have) Change-Id: I40fd720a9a75b809f24ca135c4ddb0ce61ecbe41 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94056 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-03-27tdf#131399 Update java settings after slight java version changeilhan Under linux, the version is now also checked for changes at startup of libreoffice. Change-Id: I572f718cf5afc83a70d98a6897f1d3d6877644f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91037 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> 2019-10-24Introduce OStringCharStephan Bergmann ...similar to OUStringChar, to be used in string concatenation expressions. And enable the corresponding loplugin:stringadd check, and fix its findings. Change-Id: I35ebb2253ba82bda6c98ae6ebd2ad4f27cf9abf9 Reviewed-on: https://gerrit.libreoffice.org/81456 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-10-17Rename OUStringLiteral1 to OUStringCharStephan Bergmann It started out as a wrapper around character literals, but has by now become a wrapper around arbitrary single characters. Besides updating the documentation, this change is a mechanical for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f Reviewed-on: https://gerrit.libreoffice.org/80892 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-04-26tdf#42949 Fix IWYU warnings in jvmfwk/ & jvmaccess/Gabor Kelemen Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I6c1041f261ba5a6f81efd3dcbc12baf2746e1839 Reviewed-on: https://gerrit.libreoffice.org/71217 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2019-04-09tdf#124503: Support JRE installations with unknown java.vendor propertyStephan Bergmann After recent additions of 61c4f96d6ae6a80370774e53287edb27cbce8067 "Support AdoptOpenJDK" and 41507db590b24e1b9b45d95cad55c71ba2e4091d "Support Amazon Corretto" to our hard-coded list, there is now reports that at least Debian and Ubuntu tried to distribute versions of OpenJDK with the java.vendor propety set to string like "Debian" or "Ubuntu". Instead of trying to catch up with an ever-growing hard-coded list, it is probably better to stop relying exclusively on such a hard-coded list, and for unknown vendor values, try out whether the SunInfo backend (which supports the "generic" OpenJDK) would be able to handle the given JRE. (For simplicity, assume that any versions of such JREs are supported. Our baseline is Java 6, and there are unlikely any older versions of JREs from unknown vendors out there. If this turns out to be problematic, we could include information about problematic vendors after all, or add a general check that JREs from unknown vendors are at least Java 6.) Many functions in jvmfwk/inc/vendorplugin.hxx that used to take a set of sVendor/sMinVersion/sMaxVerison/arExcludeList paramters had to be revised to take a vendorSettings parameter instead, and VendorSettings::getVersionInformation has been changed to return a boost::optional, so that unknown vendors can be handled gracefully. Change-Id: Ibf915f2ddd59e09b77e2c03be688cac0547b9ac9 Reviewed-on: https://gerrit.libreoffice.org/70460 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-03-31tdf#120703 PVS: Silence V575 warningsMike Kaganski V575 The potential null pointer is passed into 'foo' function Add asserts to those cases that are related to OOM cases. There's nothing to be done if the assertions fail anyway. Change-Id: I92ac95d44f512aa1948b1552b0e1f6da695a9f92 Reviewed-on: https://gerrit.libreoffice.org/70008 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2019-02-09loplugin:indentation in jvmfwk..lotuswordproNoel Grandin Change-Id: I1af665f4c6d34d8514dd23bb7a3eba700ce3ddbc Reviewed-on: https://gerrit.libreoffice.org/67559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-01-22Silence bogus -Werror=clobbered (GCC 7 --enable-optimized)Stephan Bergmann > In file included from gcc/include/c++/7.1.1/vector:69:0, > from jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx:39: > gcc/include/c++/7.1.1/bits/vector.tcc: In function ‘javaPluginError jfw_plugin_startJavaVirtualMachine(const JavaInfo*, const JavaVMOption*, sal_Int32, JavaVM**, JNIEnv**)’: > gcc/include/c++/7.1.1/bits/vector.tcc:407:15: error: variable ‘__new_finish’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered] > pointer __new_finish(__new_start); > ^~~~~~~~~~~~ Change-Id: Iefabac65871ed79bcfa333f0193fcbbd1369f7f1 Reviewed-on: https://gerrit.libreoffice.org/66714 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>