Age | Commit message (Collapse) | Author |
|
Change-Id: I05f3b171578b8fef5b15dcbbf10ae9b7cf2d1b02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133075
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
...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>
|
|
Change-Id: I049148d82eb306e8ba7fdc9f0cc650f45b05da0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125257
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...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>
|
|
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I6f2e29d2e7908a40175dc2852e955f0a1bc501e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108481
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...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>
|
|
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>
|
|
Change-Id: If01e7c0d7d87a544f6601174ce43b37c63cfbcb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101746
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I979e9142324df589229aafbb4a17f7495a79f0dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97594
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
...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>
|
|
Change-Id: I8b33a9cdb622edb065bceef2e9122c2fd28ce75e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94306
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Change-Id: Ic58bc539ad6b4e1ef1d8049ec97547d1420be8a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91817
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...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 "<"/">" 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>
|
|
Change-Id: Id64855e3879d21106930a4dc9c36b246deb3c6e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85818
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2
Reviewed-on: https://gerrit.libreoffice.org/85477
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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
|
|
...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>
|
|
Change-Id: I8f853990d38dd6f5dd1dd521f022e9874e1924c8
Reviewed-on: https://gerrit.libreoffice.org/84485
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...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>
|
|
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>
|
|
Change-Id: I858870d883de10a673d7ce2798bda8c8f511cee5
Reviewed-on: https://gerrit.libreoffice.org/79889
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I56a9bf698b60bd278c71cc632aacef2bd2f4c13f
Reviewed-on: https://gerrit.libreoffice.org/76501
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3c014f53607a849c743a2fd1aa47d03d5af978fb
Reviewed-on: https://gerrit.libreoffice.org/76495
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
Change-Id: I69377e2f96a376a7a5ccaec268c4f92c00a250f7
Reviewed-on: https://gerrit.libreoffice.org/70705
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie90e53583484ee4f378ec92634adf3be7cd9ecbb
Reviewed-on: https://gerrit.libreoffice.org/70650
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: Ia0cc331998d735002dda5eedff8dad3bfbd53979
Reviewed-on: https://gerrit.libreoffice.org/69235
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I1af665f4c6d34d8514dd23bb7a3eba700ce3ddbc
Reviewed-on: https://gerrit.libreoffice.org/67559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If173f42302553b164267909a0a3156bb25a6d558
Reviewed-on: https://gerrit.libreoffice.org/63957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I1df70b7dff5ebb6048f7fc618789faa15ca5d422
Reviewed-on: https://gerrit.libreoffice.org/61967
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: Icc820a47ac891c358883f9c01224f676c58fdd11
Reviewed-on: https://gerrit.libreoffice.org/59744
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...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>
|
|
...fixing regression introduced with 49eb02f07a5af44da59008a238e828b4a9532bef
"new loplugin:unusedvariablemore"
Change-Id: Ib598d67add50031937c9c9f3e23ea16d0a1da107
|
|
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>
|
|
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>
|