summaryrefslogtreecommitdiff
path: root/jvmfwk/source
AgeCommit message (Collapse)Author
2022-04-15use more string_view in jvmfwkNoel Grandin
Change-Id: I05f3b171578b8fef5b15dcbbf10ae9b7cf2d1b02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133075 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-12loplugin:stringview more o3tl conversionNoel Grandin
look for call sequences that can use string_view and the new o3tl functions in o3tl/string_view.hxx Also add a few more wrappers to said #include file Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
2022-01-27Recheck modules [i-l]* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I758bb27e93779e3df21c463714e49354748f446f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128715 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-11-17Don't fail jfw_findAllJREs for just one JRE of WrongArchStephan Bergmann
...otherwise if one such JRE had found its way into a user's configuration, "Tools - Options... - LibreOffice - Advanced" would no longer show *any* JREs. Regression introduced with 9143dd4ebe37b608e43d04434cf831624bf55b65 "Related tdf#54443 List only matching JREs", which added WrongArch to the javaPluginError enum. Change-Id: I51fd47e585c6686be7a9282615c0978e4f6c460b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125396 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-21Restrict macOS ARM64 to Java >= 17Stephan Bergmann
The commit message of e529461bcb126e0975ffa3f86e1fd5a630551de2 "Enable JVM also on macOS ARM64" had identified <https://cdn.azul.com/zulu/bin/zulu17.0.63-ea-jdk17.0.0-ea.27-macosx_aarch64.zip> "to work reliably now" while other (older Zulu) JVMs "have always crashed with SIGBUS that smelled like our uses of pthread_jit_write_protect_np in bridges/source/cpp_uno/shared/vtablefactory.cxx colided with corresponding calls in the in-process JVM". Those observations would be in line with <http://openjdk.java.net/jeps/391> "JEP 391: macOS/AArch64 Port" only implemented for Java 17 now (see <https://github.com/openjdk/jdk/commit/dbc9e4b50cdda35f5712deaf440c49f50b9edc96> "8253795: Implementation of JEP 391: macOS/AArch64 Port"). So for macOS ARM64 assume that all OpenJDK variants (i.e., providing an empty jvmfwk/distributions/OpenOfficeorg/javavendors_macosx_aarch64.xml) of at least Java 17 (i.e., building on recent 3460c16d7f749d8d2a59d8b927df5ec31f64a083 "Make getVersionInformation always return a VersionInfo" and "change the hardcoded '1.8.0' to '17' for just that one platform") work. Change-Id: I11e8ba232cee066a25a49edebd0cc50e24e84124 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123989 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-09-01clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-04Fix alternate JREs missing bin/ directory on java.library.pathSamuel Mehrbrodt
Exception looks like this: java stack trace: java.lang.UnsatisfiedLinkError: zulu11\bin\fontmanager.dll: Can't find depende nt libraries at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442) at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498) at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2648) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830) at java.base/java.lang.System.loadLibrary(System.java:1873) at java.desktop/sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:57) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32) at java.desktop/sun.font.SunFontManager$1.run(SunFontManager.java:279) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.SunFontManager.<clinit>(SunFontManager.java:275) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:398) at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:82) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.ja va:189) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnviron ment.java:223) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnviron ment.java:251) Change-Id: I7a16bb5813d4c089ddb4de34a250280cf6fee137 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119880 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2021-04-21loplugin:stringadd replace OUStringLiteral temporaries with OUString::ConcatNoel Grandin
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-29loplugin:stringviewparam extend to new..Noel
O[U]StringBuffer methods Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-02Use Unicode paths on Windows for jvmfwkMike Kaganski
Change-Id: I6f2e29d2e7908a40175dc2852e955f0a1bc501e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108481 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-10-22Only read Java settings files in application modeMichael Weghorn
The 'javasettings_${_OS}_${_ARCH}.xml' files are only meant to be used when the application mode of the Java framework is used, not in direct mode. From ure/source/README: > You can also use the > UNO_JAVA_JFW_JREHOME deployment variable to specify the location of a JDK/JRE > installation. For more information on this variable, see > http://udk.openoffice.org/common/man/spec/javavendorextension.sxw. From that http://udk.openoffice.org/common/man/spec/javavendorextension.sxw : > The direct mode of the framework is used within the build environment. > Java is needed there in order to register Java UNO components with the > regcomp tool. Direct mode means that no settings are written or read. > That is the parameters UNO_JAVA_JFW_USER_DATA and > UNO_JAVA_JFW_SHARED_DATA are not used. > [...] > Another example for using the direct mode is the SDK. The SDK uses the > libraries from the office installation. When an SDK is configured then > one specifies what Java is to be used. This Java shall then be used for > all task which require Java including registration of UNO components. In > order to override the java settings of the office the script which > prepares the SDK environment sets these environment variables: > UNO_JAVA_JFW_JREHOME=<file_URL_to_selected_Java> > UNO_JAVA_JFW_ENV_CLASSPATH=true > UNO_JAVA_JFW_VENDOR_SETTINGS=<file_URL_to_javavendors.xml_from_OOo> > By setting UNO_JAVA_JFW_JREHOME the framework is switched into direct mode > and the office settings are disregarded. Therefore, don't try to read the settings when using direct mode. This makes the relevant code path for accessing the settings conditional on 'jfw::JFW_MODE_APPLICATION' being used. Otherwise, using direct mode e.g. by starting LibreOffice using UNO_JAVA_JFW_JREHOME=file:///usr/lib/jvm/java-11-openjdk-amd64/ ./instdir/program/soffice --writer then going to the "Advanced" options in "Tools" -> "Options", where the Java settings reside would result in this SAL_WARN being triggered warn:jfw:10207:10207:jvmfwk/source/framework.cxx:119: [Java framework] Trying to access settings files in direct mode. and no JVM at all being shown in the list of available Java installations. Change-Id: I2b98d822aed2b160f970c50ca695a9f3beeacd34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104001 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-08-31Simplify some code involving SAL_PATHSEPARATOR and OString/OUStringBufferStephan Bergmann
Change-Id: If01e7c0d7d87a544f6601174ce43b37c63cfbcb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101746 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: jvmfwkStephan Bergmann
Change-Id: I979e9142324df589229aafbb4a17f7495a79f0dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97594 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-22tdf#134167: jfw_plugin_getAllJavaInfos can successfully return empty listStephan Bergmann
Regression introduced with 6ba74150866d71469827de9f4f19268dfa7db137 "jfw::isAccessibilitySupportDesired is obsolete" Change-Id: I696f3240fa8760ae156ac3b8b1fd1fe42f81c539 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96821 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-15Typo in commentStephan Bergmann
Change-Id: I8b33a9cdb622edb065bceef2e9122c2fd28ce75e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94306 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-07jfw::isAccessibilitySupportDesired is obsoleteThorsten Behrens
There's no platform left that would require java accessibility. Change-Id: I2149f619e20aae70d7713d223985f8016ade8e77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93600 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-07loplugin:flatten in jvmfwkNoel Grandin
Change-Id: Ic58bc539ad6b4e1ef1d8049ec97547d1420be8a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91817 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-09improve loplugin:unusedfieldsNoel Grandin
noticed something that wasn't being picked up, wrote some tests, and found an unhandled case in Plugin::getParentFunctionDecl Change-Id: I52b4ea273be6614e197392dfc4d6053bbc1704de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90141 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-21Drop o3tl::optional wrapperStephan Bergmann
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-03tdf#96505: Get rid of cargo cult long integer literalsDesmin Alpaslan
Change-Id: Id64855e3879d21106930a4dc9c36b246deb3c6e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85818 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-19sal_Char->char in idlc..linguisticNoel Grandin
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2 Reviewed-on: https://gerrit.libreoffice.org/85477 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-14Remove JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY, JFW_PLUGIN_FORCE_ACCESSIBILITYStephan Bergmann
JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY is no longer set anywhere since 6dcb3d4ef46312729bb6f16c473b433474863f68 "Related fdo#51252: No more prereg, no more unopkg sync" in 2012. JFW_PLUGIN_FORCE_ACCESSIBILITY had been introduced with 72b954df59d64fa47f6380e4322243401afb683f "Avoid using gconftool. Atk provides a11y not Java on Unix" in 2013, as a means for users on Unix-like systems to still force a JVM with a11y support, even though that should no longer be necessary for LO a11y. Both environment variables were documented as "unofficial", with the warning that the "may be removed in the future." Theoretically, they could still be set by some users, but the likelihood of their relevance today is considered low. Change-Id: Ib718fb275b67a6de7fd7bc88ae428fd60168f4f4 Reviewed-on: https://gerrit.libreoffice.org/85140 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Jenkins
2019-12-14Remove unused jvmfwk *rc filesStephan Bergmann
...and accompanying readme.txt. In the past, they got copied to "solver" and were used during the build. bf0e30f9cdee963d3cf889305c85b53c21b8c974 "jvmfwk: remove Package_*solver" stopped copying them. From jvmfwk3rc, the UNO_JAVA_JFW_ENV_JREHOME/CLASSPATH=true settings are found in OfficeConnection::setUp (unotest/source/cpp/officeconnection.cxx) and org.openoffice.test.OfficeConnection.setup (unotest/source/java/org/openoffice/test/OfficeConnection.java), used during tests. Setting UNO_JAVA_JFW_VENDOR_SETTINGS appears to not be necessary there (presumably because those UNO_JAVA_JFW_ENV_* settings override its use anyway?). The JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 in sunjavapluginrc had been added as the fix for <https://bz.apache.org/ooo/show_bug.cgi?id=40879> "java framework: registration of Java components may fail", most of the relevant commit messages mention "#i40879# in build environment the JRE is not tested for accessibility, because of potential X server problems". There appears to be no replacement that still sets it in post "solver" times, presumably because that hack is just no longer relevant. Change-Id: I3028b2f69c00eed3c5d2103345773b8daac409a0 Reviewed-on: https://gerrit.libreoffice.org/85136 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05Fix typoAndrea Gelmini
Change-Id: I8f853990d38dd6f5dd1dd521f022e9874e1924c8 Reviewed-on: https://gerrit.libreoffice.org/84485 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-12-01Introduce o3tl::optional as an alias for std::optionalStephan Bergmann
...with a boost::optional fallback for Xcode < 10 (as std::optional is only available starting with Xcode 10 according to <https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite all code to use o3tl::optional instead of boost::optional. One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus -Werror=maybe-uninitialized" should no longer be necessary (and whose check happened to no longer trigger for GCC 10 trunk, even though that compiler would still emit bogus -Wmaybe-uninitialized for uses of boost::optional under --enable-optimized, which made me ponder whether this switch from boost::optional to std::optional would be a useful thing to do; I keep that configure.ac check for now, though, and will only remove it in a follow up commit). Another longer-term benefit is that the code is now already in good shape for an eventual switch to std::optional (a switch we would have done anyway once we no longer need to support Xcode < 10). Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses boost::property_tree::ptree::get_child_optional returning boost::optional, so let it keep using boost::optional for now. After a number of preceding commits have paved the way for this change, this commit is completely mechanical, done with > git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g' (before committing include/o3tl/optional.hxx, and relying on some GNU features). It excludes some files where mention of boost::optional et al should apparently not be changed (and the sub-repo directory stubs). It turned out that all uses of boost::none across the code base were in combination with boost::optional, so had all to be rewritten as o3tl::nullopt. Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b Reviewed-on: https://gerrit.libreoffice.org/84128 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-01loplugin:stringadd in helpcompiler..ooxNoel Grandin
Change-Id: I858870d883de10a673d7ce2798bda8c8f511cee5 Reviewed-on: https://gerrit.libreoffice.org/79889 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-29loplugin:sequentialassignNoel Grandin
Change-Id: I56a9bf698b60bd278c71cc632aacef2bd2f4c13f Reviewed-on: https://gerrit.libreoffice.org/76501 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-28loplugin:oncevarNoel Grandin
Change-Id: I3c014f53607a849c743a2fd1aa47d03d5af978fb Reviewed-on: https://gerrit.libreoffice.org/76495 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-15improve loplugin simplifyconstructNoel Grandin
to find stuff like OUString s = OUString("xxx") Change-Id: Ie7ed074c1ae012734c67a2a89c564c1900a4ab04 Reviewed-on: https://gerrit.libreoffice.org/70697 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-13loplugin:sequentialassign in embeddedobj..l10ntoolsNoel Grandin
Change-Id: I69377e2f96a376a7a5ccaec268c4f92c00a250f7 Reviewed-on: https://gerrit.libreoffice.org/70705 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-12loplugin:unusedmethodsNoel Grandin
Change-Id: Ie90e53583484ee4f378ec92634adf3be7cd9ecbb Reviewed-on: https://gerrit.libreoffice.org/70650 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-18Index is not needed for single getToken callMatteo Casalin
Change-Id: Ia0cc331998d735002dda5eedff8dad3bfbd53979 Reviewed-on: https://gerrit.libreoffice.org/69235 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.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>
2018-11-25tdf#120703 PVS: V560 A part of conditional expression is always true/falseMike Kaganski
Change-Id: If173f42302553b164267909a0a3156bb25a6d558 Reviewed-on: https://gerrit.libreoffice.org/63957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-10-19clang-tidy readability-container-size-emptyNoel Grandin
Change-Id: I1df70b7dff5ebb6048f7fc618789faa15ca5d422 Reviewed-on: https://gerrit.libreoffice.org/61967 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-17New loplugin:externalStephan Bergmann
...warning about (for now only) functions and variables with external linkage that likely don't need it. The problems with moving entities into unnamed namespacs and breaking ADL (as alluded to in comments in compilerplugins/clang/external.cxx) are illustrated by the fact that while struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } returns 1, both moving just the struct S2 into an nunnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { namespace { struct S2: S1 { int f() { return 1; } }; } int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } as well as moving just the function f overload into an unnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; namespace { int f(S2 s) { return s.f(); } } } int main() { return f(N::S2()); } would each change the program to return 0 instead. Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c Reviewed-on: https://gerrit.libreoffice.org/60539 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-29Replace find_if with proper quantifier algorithmsArkadiy Illarionov
Change-Id: Icc820a47ac891c358883f9c01224f676c58fdd11 Reviewed-on: https://gerrit.libreoffice.org/59744 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-06Add missing sal/log.hxx headersGabor Kelemen
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it. This is a continuation of commit 6ff2d84ade299cb3d14d4110e4cf1a4b8070c030 to be able to remove those unneeded includes. This commit adds missing headers to every file found by: grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG') in files formerly omitted for oversight or non-cxx extension Change-Id: I327c573f44076c6ccfecf737eafccba2da72e1bd Reviewed-on: https://gerrit.libreoffice.org/58600 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-07-26jvmfwk: avoid -Werror=deprecated-copy (GCC trunk towards GCC 9)Stephan Bergmann
...by removing explicitly user-provided functions that do the same as their implicitly-defined counterparts, but may prevent implicitly declared copy functions from being defined as non-deleted in the future. (Even if a dtor was declared non-inline in an include file, the apparently-used implicitly-defined copy functions are already inline, so why bother with a non-inline dtor.) Change-Id: I1330a9fd4fc7f8fe8525b3ea02f9edb9e88e6638 Reviewed-on: https://gerrit.libreoffice.org/58059 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-04-12Keep strings alive again as necessaryStephan Bergmann
...fixing regression introduced with 49eb02f07a5af44da59008a238e828b4a9532bef "new loplugin:unusedvariablemore" Change-Id: Ib598d67add50031937c9c9f3e23ea16d0a1da107
2018-04-11new loplugin:unusedvariablemoreNoel Grandin
collection of heuristics to look for local variables that are never read from i.e. do not contribute to the surrounding logic This is an expensive plugin, since it walks up the parent tree, so it is off by default. Change-Id: Ib8ba292241bd16adf299e8bba4502cb473513a06 Reviewed-on: https://gerrit.libreoffice.org/52450 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-28Don't pass empty option to JNI_CreateJavaVMStephan Bergmann
sUserClassPath may be empty (instead of containing "-Djava.class.path=...") here, which older versions of Java have apparently silently ignored. But Java 10 now fails with JNI_EINVAL (-6). (Happens e.g. during CppunitTest_dbaccess_hsqldb_test.) Change-Id: Ifd13222f0d0ae69547bd1a9fe0fd5eae47917d0a Reviewed-on: https://gerrit.libreoffice.org/51949 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>