Age | Commit message (Collapse) | Author |
|
With Add/Delete decimal place, insert percent char
and string text between number and '%'
Change-Id: I4a97e4361228020803810692d7977e5806baf180
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94757
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This popped up when attempting to replace the zh-CN keyword
'General' with '常规' for tdf#88233, which led to
CppunitTest_sc_subsequent_export_test failing for
ScExportTest::testNatNumInNumberFormatXLSX with
- Expected: [DBNum2][$-804]General;[RED][DBNum2][$-804]General
- Actual : [$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al"
The reason was that from the English format string loaded from .xlsx
[DBNum2][$-804]General;[RED][DBNum2][$-804]General
the resulting zh-CN format was
[DBNum2]General;[RED][DBNum2][$-804]General
like before, which when reparsed in a zh-CN locale now without the
'General' keyword first led to
[DBNum2]GEnERal;[RED][DBNum2][$-804]GEnERal
with GE and ER calendar keywords, which then is exported correctly as
[$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al"
So when detecting the "format belongs to another locale" condition
also switch the target locale of the ongoing conversion, which
results in the then correct
[DBNum2]常规;[RED][DBNum2][$-804]常规
exported as
[DBNum2][$-804]General;[RED][DBNum2][$-804]General
again.
Such could had happened with any format code using a [$-...]
locale modifier if keywords differ between originating and target
locale, but cases seem to be not that widespread.
Change-Id: Ib4d444a4085ace251d03e87498eb0f4871eadc8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94313
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8dc11da4e1de5c2e2831ac85dff0daeac0e0ce95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93744
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and so SetSearchMask which doesn't have any effect anymore
Change-Id: I0b7f402ce0317971d5196fc448fe2945a6a292f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93393
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
surely the current searchmask should have no effect on the remove seeing as a
new style is going to be created unilaterally
Change-Id: I4a8d05be26a3a2711ae6f377f034a9155100e831
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93496
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I19ee6a916017cb49092a2b74bc2bfd9b99b8c72d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93489
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
if there isn't one we shouldn't need to create one to invalidate it
Change-Id: Ia936f71c18c45d8e08f013ffa143c196109495ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93471
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7bc570899170b7a21e4d54e58d7a8ada0f79b918
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93469
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic7da569f9133d31783c238d7ca4a4cc1ae0244f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93468
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I36655b65ca00e5f7b8779a28d4a1778c8e35dc4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93461
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
and use CreateIterator to make it explicit what is being counted
Change-Id: I8d76aef601533960a23c056b83a48c4f130bbe75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93446
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and update pches accordingly
Change-Id: I411712532fd85961bffe6678416fcdc1d9c7f53d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92617
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
In preparation of further detailed handling.
Change-Id: I9e4d916de031b742d0af1025b945b7608fed8266
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92462
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I979faf4c476a7de91a0b6e06dd8717cee25525f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92313
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found by:
run-clang-tidy-10 -checks=-*,misc-unused-using-decls
Change-Id: I3e95791e223ef01e140a6217e29a9efae428a784
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90876
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Iba46fbe8559211403118a23cd198a2217b333a81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90900
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I91235eee8c6a9d4a59c1933527b49141f64cd91b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90478
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit 5181253946ca1877cc42050452aa6d733d6da3f1.
Change-Id: I30e30aae45c33824c0df823a9fad710faa81ea3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90453
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifa76e004128223460945d58d1c59c4e23db0f108
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90370
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... representation of given decimal.
Use dtoa.c from https://www.netlib.org/fp/dtoa.c to build a custom
static library that doesn't use current locale (unlike strtod from
stdlib.h). This is the implementation used by e.g. python and nss
(search for "dtoa.c" under UnpackedTarball).
To avoid name clash with the standard strtod, rename the function
to strtod_nolocale.
Size of buffer on stack in ImpSvNumberInputScan::StringToDouble is
256 characters. Logging function usage in make check, of ~124 600
invocations, the longest string was 14 characters, average being
2.1 characters. So heap allocation is unlikely in scenarios with
intensive function usage.
After std::from_chars is available in baseline compilers, external
library can be dropped, and call to strtod_nolocale replaced with
the standard function.
The artifact at https://dev-www.libreoffice.org/src/dtoa-20180411.tgz
is created with
mkdir dtoa && mkdir dtoa/src && wget https://www.netlib.org/fp/dtoa.c -O dtoa/src/dtoa.c && \
printf 'd8bab255476f39ea495c8c8ed164f9077da926e6ca7afb9ad3c56d337c4484fe dtoa/src/dtoa.c' | sha256sum -c && \
tar -c --owner=0 --group=0 --mode=go=r,u=rw --mtime='Wed, 11 Apr 2018 15:59:39 GMT' dtoa/src/dtoa.c | gzip -n > dtoa-20180411.tgz && \
printf '0082d0684f7db6f62361b76c4b7faba19e0c7ce5cb8e36c4b65fea8281e711b4 dtoa-20180411.tgz' | sha256sum -c
(where the date "Wed, 11 Apr 2018 15:59:39 GMT" is from
`wget -S https://www.netlib.org/fp/dtoa.c`
"Last-Modified: Wed, 11 Apr 2018 15:59:39 GMT" header).
Change-Id: Ia61b7678e257c4bc1ff193f3f856d611aa5c1a21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
In LOK we use one language identifier for both - UI language and
the locale used. This is a problem when we determine that we a
language for UI is not available and fall-back to the default
"en-US" langauge, which also changes the locale. This introduces
a separate variable that stores the language tag for the locale
independently to the language.
Another problem is that in some cases we don't reset the staticly
initialized data, when the new document is loaded, which is on
the other hand used to define which currency symbol is used as
SYSTEM locale. That can in some cases select the wrong currency
symbol even when we changed the locale to something else. This fix
introduces a reset function, which is triggered on every document
load.
Change-Id: I55c7f467600a832895f94346f8bf11a6ef6a1e49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89320
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89343
Tested-by: Jenkins
|
|
Add a predefined NF_DATETIME_SYS_DDMMYYYY_HHMM format code with
formatindex="50" to all locale data files, which shifts all
reserved area internally generated built-in formats up by one.
Reserved area was filled already so that boundary has to be
increased as well. Add some flexibility for future additions by
setting the new boundary to 65, free first format index to be used
by additional locale data formats is 66 now. Adapt all locales to
the new boundary.
The existing predefined NF_DATETIME_SYSTEM_SHORT_HHMM format code
with formatindex="46" mostly was and is used with 2-digit years
(stemming back from the old binary format and Excel
compatibility), some locales that don't use 2-digit years at all
already defined it to 4-digit years. Keep those but move the
default="true" attribute (if so) to the new "50" format.
Modify populating the format list such that resulting duplicates
will be suppressed there as well.
Also try to match the new format in ODF import if a long year was
requested with date+time.
Finally set the new format as default for all *_IT locales. In
future changing the default date+time format to 4-digit year is
just a matter of moving the default="true" attribute to the new
format.
Change-Id: Ib16aa9fda0e71b2d03f78e3dd013785de03cd288
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89265
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
JunitTest and PythonTest modules check for these themself.
Change-Id: Ia453bc99571738b01cc8f161f346cb6c37b2e429
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88832
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I9a7c98b656c1f9270de5b13f7022d5930a665a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88760
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ibc231308d0fc93085933ae7d80dc8c4b2699fe02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88204
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
show Korean Dangi Calendar format
Ref1: MSDN - Calendar IDs
5 : CAL_KOREA
https://docs.microsoft.com/en-us/windows/desktop/Intl/calendar-identifiers
Ref2: stackoverflow
https://stackoverflow.com/questions/54134729/what-does-the-130000-in-excel-locale-code-130000-mean
Change-Id: Ia1f367bfd5c13f29054064d89be847bbf249c0d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87689
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
With --enable-pch=full there's not much difference between a "public"
header in <module>/inc and a private one in <module>/src/somewhere/inc .
And since the script searches recursively, this apparently helps to
find even more headers for lower pch levels.
Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and
cid#1458017 silence Out-of-bounds write
Change-Id: I5411322bca523e5dc55b8df2e7d9261981f504da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87703
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
cid#1458018 Untrusted loop bound
cid#1242844 Untrusted loop bound
Change-Id: I9062240290708f4b51b0ce42a30897b50d1a2677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87702
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie5a381fc5e5b73490ab8b2036ef2a1164e475e8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87557
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
found by my new aggressive unused var plugin. these are unused return
values from function calls
Change-Id: I3359c583f535828f192cb833762dfedc008d82f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87439
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I067ea2f3cb651fdc5c3d1a09b0c55583618b9d1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87355
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ice7c0ecc8ee05a5c3b0af458ceeee8191bdde322
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86752
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I01c4bfadfabce128f1e28b0c871da1722b865b6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86377
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This is checked several lines below, with much stricter range.
Change-Id: I3bfaf71f9e40dd1af089ed1ac238bc2939d0fc3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86392
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ideb61209e8795865bce6e0b1d667b34f8a8db4d9
Reviewed-on: https://gerrit.libreoffice.org/85713
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic7b78dffb2f8d1908f3263d88c5912aec2ebce8b
Reviewed-on: https://gerrit.libreoffice.org/85263
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and can then remove some casting
Change-Id: Id821c32ca2cbcdb7f57ef7a5fa1960042e630ffc
Reviewed-on: https://gerrit.libreoffice.org/85022
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I89ff5493c70d6e64ee6ab65b1b789a0db543c0aa
Reviewed-on: https://gerrit.libreoffice.org/84917
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Same as 97b3e455802cfc08568ec5e8379c509efe3e47b1 "Fix some new dependencies on
boost_headers"
Change-Id: I0f10374650847f4c50a8cff530c15e65906865ad
Reviewed-on: https://gerrit.libreoffice.org/84672
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t
backward compatibility remediation", as implemented now by <https://gcc.gnu.org/
git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++:
P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads
that would print an integer rather than a (presumably expected) character.
But for simplicity (and to avoid issues with non-printing characters), keep
printing an integer here.
Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7
Reviewed-on: https://gerrit.libreoffice.org/84348
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t
backward compatibility remediation", as implemented now by <https://gcc.gnu.org/
git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++:
P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads
that would print a pointer rather than a (presumably expected) string.
But here it should be fine to print pointers, esp. as there are null pointers
involved.
Change-Id: I62fad4cb9eaaa612989f035f686086ef29093d70
Reviewed-on: https://gerrit.libreoffice.org/84351
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which merely announce that the next declaration is a class
Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc
Reviewed-on: https://gerrit.libreoffice.org/84229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Similarly to commit fb1b461208e7a2760fa1c018db08606a9b3e435d replace
new instances of boost/property_tree/ptree.hpp with forward declaration
only header, as suggested by IWYU
This reduces includebloat from 28.5G to 22.6G and cold clean build time from
real 68m54,192s
user 947m28,508s
to
real 62m50,689s
user 861m33,131s
on my machine.
Change-Id: I5530f1b4b1a46d9159c752ad5af9a408215baf40
Reviewed-on: https://gerrit.libreoffice.org/84175
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|