summaryrefslogtreecommitdiff
path: root/jvmfwk
AgeCommit message (Collapse)Author
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-02tdf#129264: Make javaldx always print a line upon successful executionStephan Bergmann
...where "do not use a JRE" (implying that the printed line consists of just a terminating newline) is a sufficient condition for a successful execution, too. (Also, it appears that extend_library_path in desktop/unx/source/start.c would have introduced unwanted empty segments into the path environment variable when the line printed by javaldx consisted of just a terminating newline.) Change-Id: Ic2f86de8a829b3dea51c0e4da1ac236298e16366 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97756 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-27tdf#131572 Add java 9 module info for libreoffice.jarSamuel Mehrbrodt
Add a java module named "org.libreoffice.uno" for this jar. This needs to be compiled with Java 9. But since we want to keep b/c with Java 8, the rest of the jar has to be compiled with Java 8. This bumps the *build* requirement to Java 9 while keeping the *runtime* requirement at Java 8. The gbuild JavaClassSet class is changed to invoke javac twice, where the 2nd invocation compiles with --release 9 and a --patch-modules argument so that it finds the results of the first invocation and also the javamaker generated files in CustomTargets. Change-Id: I888f5dbe097cc37136e68db5919939877c981862 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91105 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.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-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-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-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-04-07new loplugin:unusedvariableplusNoel Grandin
a particularly aggressive checker, which is why it is off by default Change-Id: Id5a0faa50b3ecc75e01f4aedc6579c5209e585da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91643 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>
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-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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>
2020-01-25tdf#130137 Replace remaining uses of WNT define checks with _WIN32A_GAN
Change-Id: If95f1ea5a81de62eb4f725e5fcb30ccb8530062a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87372 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-14loplugin:finalclasses in i18npool..linguisticNoel Grandin
Change-Id: Ib903fb2fdb4c4c25f73053065b828dade8b63785 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86687 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-16unused #includeStephan Bergmann
...after c0ac7ae73480cd2b01f24e88c01bee507e8638f9 "Remove JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY, JFW_PLUGIN_FORCE_ACCESSIBILITY" Change-Id: I359255127782efa061f1daa35e524fb414a0160c Reviewed-on: https://gerrit.libreoffice.org/85202 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-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-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-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-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-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-08-12Fix typosAndrea Gelmini
Change-Id: Icdc486d64283961dad4a1d29ae662d66143f674b Reviewed-on: https://gerrit.libreoffice.org/77320 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-04Fix typoAndrea Gelmini
Change-Id: I2991d07cb777ee83c24931798035fcc17ae48662 Reviewed-on: https://gerrit.libreoffice.org/76908 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): jvmfwkStephan Bergmann
Change-Id: I2bf2c6b5a896cc58195a5b8f85274b9d17c56ac8 Reviewed-on: https://gerrit.libreoffice.org/76667 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-29Avoid memcpy nonnull issueStephan Bergmann
...as started to get reported by <https://ci.libreoffice.org/job/lo_ubsan/1341/> > /jvmfwk/plugins/sunmajor/pluginlib/util.cxx:368:33: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:43:28: note: nonnull attribute specified here > #0 0x2b710cdb4e35 in jfw_plugin::AsynchReader::execute() /jvmfwk/plugins/sunmajor/pluginlib/util.cxx:368:13 > #1 0x2b70c87b8a27 in salhelper::Thread::run() /salhelper/source/thread.cxx:40:9 > #2 0x2b70c87bac9f in threadFunc /include/osl/thread.hxx:185:15 > #3 0x2b70ba8bb89d in osl_thread_start_Impl(void*) /sal/osl/unx/thread.cxx:235:9 > #4 0x2b70bc47fdd4 in start_thread (/lib64/libpthread.so.0+0x7dd4) > #5 0x2b70bcdb4eac in clone (/lib64/libc.so.6+0xfdeac) during UITest_calc_tests6 Change-Id: I6505061192a8d6b9a68d72980fd134d161e5e1a3 Reviewed-on: https://gerrit.libreoffice.org/76516 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-07-26Bump Java baseline to Java 8Stephan Bergmann
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2019-July/083193.html> "Minutes of ESC call: 2019-07-25". 3d27b2fa9c5a03f78e5145377402f8a88e3da1be "tdf#124503: Support JRE installations with unknown java.vendor property" had added support for JREs with unknown vendor strings without checking that those JREs have a matching version (Java 6 back then, Java 8 now). That check has still not be implemented, assuming that Java 8 is old enough in practice so that any such JRE encountered in the wild will at least be Java 8 anyway. Change-Id: I0205a34955368067c698bcabd24de84205a382bd Reviewed-on: https://gerrit.libreoffice.org/76365 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-17simplify codeStephan Bergmann
...following up on b70ab9e9e5630a965c5e6cc40c2480dddf1e2384 "Fix swapping of vector elements" Change-Id: Ib67b43345fa808bc25dff5aff11b387bb3455464 Reviewed-on: https://gerrit.libreoffice.org/74173 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-06-11Fix swapping of vector elementsStephan Bergmann
...which had been broken with edc85fb55f8adc30a1416c6c854c89097060fb21 "clang-tidy performance-unnecessary-copy-init in idl..reportdesign" (and could cause "Tools - Options... - LibreOffice - Advanced - Java Options" to erroneously list a single JRE multiple times, instead of listing different JREs). Change-Id: I6799903be39a5c6aa601131fad6eab3edea8d9e4 Reviewed-on: https://gerrit.libreoffice.org/73679 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-27osl/diagnose.h and diagnostics.h are used when OSL_DEBUG_LEVEL >= 2Tomoyuki Kubota
Change-Id: I004ee1a56b0d4c63db82106c516e19753ad2a0f5 Reviewed-on: https://gerrit.libreoffice.org/71405 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>
generated by cgit (git 2.34.1) at 2025-01-12 22:45:03 +0000