As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is
apparently dead and should thus be removed. However, that was the only bridge
implementation for 32-bit S390, which implies that support for the 32-bit S390
architecture as a whole is dead and should thus be removed.
Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
1. Configure gbuild
2. Add UNO Bridge for riscv64
Till now base function works well on riscv64. The bridgetest has passed.
Test on Debian, Gentoo and openEuler.
Credits:
- Heiher <r@hev.cc> and Stephan Bergmann <sbergman@redhat.com>
The riscv64 bridge implementation refers to mips64 and
AArch64 bridges.
- Bo Yu <tsu.yubo@gmail.com> configures gbuild for riscv64.
- WANG Xuerui <xen0n@gentoo.org> provides lots of guiding tips.
Change-Id: Ifad3b0de8b2c9e7328627ed03396bbd45a9c71e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137445
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
...even for JREs not listed in javavendors.xml, making it default to a
VersionInfo with sMinVersion = "1.8.0".
3d27b2fa9c "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>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "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>
...now that 6ba7415086
"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 6873b3be47 "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>
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
358146bbbd "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>
...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
fed7c3deb3 "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>
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>
After recent additions of 61c4f96d6a "Support
AdoptOpenJDK" and 41507db590 "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>
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 6ff2d84ade 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')
to directories from filter to jvmfwk
Change-Id: I2a73d63f2aaef5f26d7d08957daaa8a30b412ac5
Reviewed-on: https://gerrit.libreoffice.org/58204
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>
Muhammad Naeem