Age | Commit message (Collapse) | Author |
|
...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>
|
|
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I47b44c80b2a5e3c9d84f5d7257efe17f138a1067
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106563
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie643402fbf10ac837c975d29068b7973e9dd6210
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105685
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I886b6f446293d3b1cfbf4ae05e8dbd7fabab9f20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105510
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.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>
|
|
32bc8ddbf335dd26019edcf12758643b4cff9913 "tdf#94716 allow Oracle's JDK to be
used on OS X 10.10 and 10.11" had restricted both addJavaInfosDirScan
(jvmfwk/plugins/sunmajor/pluginlib/util.cxx, relevant when LO scans for
available Java runtimes) and JvmfwkUtil_isLoadableJVM (which is more central and
also relevant when manually adding a Java installation on the Advanced options
page) to JDK installations under /Library/Java/JavaVirtualMachines.
Recent versions of OpenJDK for macOS are provided as *.tar.gz files (e.g.,
<https://download.java.net/java/GA/jdk15/779bf45e88a44cbd9ea6621d33e33db1/36/GPL
/openjdk-15_osx-x64_bin.tar.gz> avaiable at <http://jdk.java.net/15/>) that can
potentially be installed anywhere, so it looks useful to remove the
/Library/Java/JavaVirtualMachines restriction from JvmfwkUtil_isLoadableJVM.
I'm not sure whether that would have any nagative impact, esp. for any scenario
that would still be relevant today. When I unpacked the above
openjdk-15_osx-x64_bin.tar.gz to ~/OpenJDK/ on my macOS 10.15.6, and manually
added /Users/stephan/OpenJDK/jdk-15.jdk/Contents/Home on the Advanced options
page, everything appeared to work fine.
Change-Id: I15545cc786a4a423f3bfe22ba477a45d6ef7fdf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103212
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iea89befded02ecfd7513cc3d8f116dd6ac2913be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102859
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If01e7c0d7d87a544f6601174ce43b37c63cfbcb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101746
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ideee477b0c8f0d472a607ed69ba51351d87f61bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101010
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I4be46342b24a5993df74dbd047d88842a8df0412
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100901
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
"suspicious concatenation of string literals in an array initialization; did you
mean to separate the elements with a comma?"
Change-Id: I83828d8cc6f8ab9b0c1ca8a1c3fb528592c46504
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100897
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
...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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
...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>
|
|
...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>
|
|
Change-Id: I8b33a9cdb622edb065bceef2e9122c2fd28ce75e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94306
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(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>
|
|
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>
|
|
(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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Id64855e3879d21106930a4dc9c36b246deb3c6e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85818
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If95f1ea5a81de62eb4f725e5fcb30ccb8530062a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87372
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ib903fb2fdb4c4c25f73053065b828dade8b63785
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86687
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2
Reviewed-on: https://gerrit.libreoffice.org/85477
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
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>
|
|
...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>
|
|
...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>
|
|
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>
|
|
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>
|
|
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: Icdc486d64283961dad4a1d29ae662d66143f674b
Reviewed-on: https://gerrit.libreoffice.org/77320
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|