Age | Commit message (Collapse) | Author |
|
Change-Id: I439b9f456ac0bfaa3eb9bf17472053bd4787e828
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id83c478af5d04ad548c7cf4239fe2fb3ee154dc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103861
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It passed "make check" on Linux
Change-Id: I78ef6952782cedead97cf118588f4b7923bb0909
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103306
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Store AddParaLineSpacingToTableCells in configuration as
"AddTableLineSpacing", consistently inconsistent like AddTableSpacing
(the <desc> elements are not subject to translation).
Adapt SwCompatibilityOptPage with some ugly hacks to allow 3 different
states (TriState) for the corresponding checkbox that map to false/false,
true/false and true/true.
The checkbox widget doesn't allow to change *to* indeterminate but at
least the status of the document can be displayed this way,
with a non-obvious tweak to optcompatpage.ui to reference "checktri1"
column.
Change-Id: I5f32e05c93b5e16e782cba5d1d055809d9e5e251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103318
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...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: Iae7a028d2845d8b0bef2aefdce2ae00fa7f5660f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102110
Tested-by: Jenkins
Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
|
|
Some of the key sal_Unicode arrays contained embedded NUL characters, for which
everything after the first NUL was ignored. But from the corresponding comment,
it looks like those sal_Unicode arrays were presumably meant to contain multiple
keys that should all map to the same "English name," which I have added now.
(The original history of this source file beyond
942dbe34b9a1400c926a81f88e849d248b58ed55 "#i103496#: move some fontsubstitution
stuff from vcl to unotools to get xmloff vcl free" appears to be lost,
unfortunately. Another comment had already wondered why keys were terminated by
double NULs, where the second NUL maybe was originally meant to terminate that
sequence of individual keys all stored in a single sal_Unicode array.)
There was also another
// TODO: check if all dictionary entries are already normalized?
in the construction of the FontNameDictionary aDictionary, of which I'm not sure
what it should mean exactly, and whether I should have left it in.
(This change is a prerequisite for making the OUString ctor taking a raw pointer
explicit.)
Change-Id: I168778307a67c6b72bf483dc34bfd45f8a48a143
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102086
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Between <https://github.com/llvm/llvm-project/commit/
0e00a95b4fad5e72851de012d3a0b2c2d01f8685> "Add new warning for compound
punctuation tokens that are split across macro expansions or split by
whitespace" and <https://github.com/llvm/llvm-project/commit/
0da84535b1e328188efbc1bb697dc7276f9e7d27> "Remove
-Wcompound-token-split-by-space from -Wall", Clang 12 trunk emitted such "'::'
and '*' tokens forming pointer to member type are separated by whitespace"
warnings, so just clean those places up for good even if the warning would not
hit out of the box with any official Clang release.
Change-Id: Ic58c0da4b3dcce428f5aaa54e13d15299394cf9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101987
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>
|
|
...thereby fixing that it returns _sDefault instead of an empty string when
"version.ini (versionrc) doesn't exist"
Change-Id: Ie38afb6d87bd908f8a9773daaf5cee56751ae950
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The option to set it was removed in 5fdf2009d21fa220dfee70ea755bd698c16257a7,
and now the check is redundant - and even harmful until the remnants of the
setting is dropped from bootstrap.ini. Currently the dummy value found there
makes the About dialog miss the build id, and copying info to clipboard gives
<buildversion> instead of proper build id. Previously the string was always
empty in most builds (including TDF), which made the code proceed to buildid.
Bootstrap::getBuildVersion got unused now, and is removed.
Change-Id: If59e456655da29bb9421edc0e15d421829d0a02b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100957
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
f9e6d8d7c33a308f6f1c15929dd839de2abae3b5 "INTEGRATION: CWS nativefixer18:
fix: #124825# read build id from version.ini" from 2005 had left the previous
code to read from the bootsrap ini file as a fallback, presumably intended for
some (short) transition period.
(Plus loplugin:elidestringvar fallout. And fix the comment, which appears to
have been non-matching right from the start.)
Change-Id: Ia50228f4ae21e9f7ded48fe47d68fcd9931b090c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100967
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I85a91d24943430b42217ac91611f182059d8ec69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100919
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2fad16061bca6dc3e57926863e7a3b71947a8ade
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100139
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibe3443531c83eb44080217b61f5746be9cce9c49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99695
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5ea9e3663fc5d30d725cf18757badb9b9802da18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99675
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I17fd4156eb940fbdc925d9761301096e5349135f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99674
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iaab664770d96a7d197354949bbe6d82c248f1037
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99648
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iab187468cf25b4a4afc7c79578677156ff224df9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99651
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@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>
|
|
See tdf#74608 for motivation
Change-Id: I7a68484564aea9b416c12d5364d20ff8af77f40b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98380
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9f4684834002d09fb5408e2b705dec37ffa498fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97734
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which is both more compact code, and more efficient, since the insert
method can do smarter resizing
Change-Id: I17f226660f87cdf002edccc29b4af8fd59a25f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96948
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If77111b78496420514fb73d6d98d22e759282093
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib8947dbe464c7b5b1f6fc55e7b0754e1c75491fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95268
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib63623f5ca3f6559e02a0013c3cbd6174f7aec14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95108
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To permit pluggable crypto services, abstract existing
implementation behind an XPackageEncryption API.
Previous code already had two halfway-polymorphic classes (agile and
standard 2007 engine), so we're not adding much additional layers.
As MS crypto always uses OLE storage to wrap content into one single
file, current implementation passes all substorage names down into
XPackageEncryption APi, so different downstream implementations (e.g.
for MS RMS, or Azure AIP) are possible.
Because OleStorage classes are internal to LibO core, access is provided
via XInput/XOutput stream API function.
Change-Id: Icc32a4e0ce215090c3b739f1dcaa0654b36b7f08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84436
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I05b02a2f8b4b9091c7de0f7e98409d5b608ed250
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94610
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... to configuration and UI.
The new default is ODF 1.3 Extended, which is now ODFVER_LATEST and
stored as value "3" in configuration.
Adapt a few places related to DocumentDigitalSignatures etc. to new
default.
Change-Id: I420da4f7787cc864c6bd88470d61b146b9399aa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93177
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I644d5e418028b4b4e66cf67b20a1155a689acab0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93906
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This partially reverts fixes for i#63105 and i#71033, i.e. parts of
commits 6ca96e7aee937affef218e0bb892e6904f4ef358 and
35777f0b401ba7bee21a24c32739e86598ba608b.
Instead of using hard-coded Win-1252 for Excel files by default, use
LibreOffice locale language or default document language (as used for
old WMF, DXF and RTF files - see
20f6a6b159c69771dc0e087f63b6c701908e32e2,
1a9a77f84cac68bd5374df3e9ee4df88dc87a0ac, and
f26bbdb386f9e66b1a154d0589b1a446ea2dd8d5).
When a font in XLS specifies ANSI_CHARSET (0), allow using the default
encoding, not the corresponding Win-1252. This mimics Excel behaviour
for such fonts.
Do not use first font's encoding as file default encoding, as Excel
doesn't do that.
Do not consider font-specified encoding in ImportExcel::Rstring to
mimic Excel behaviour for cell number formats (but keep using it in
ImportExcel::ReadLabel for cell content).
Change-Id: I9860013a1244dc12f06f30c81a67909012c04913
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93612
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic97b1a4507d5629963f360147ecc20eb10f5d391
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3bfcc6fedb782b12be1fb1d42981756287f29f82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92956
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3d27837ea49ad964a40f53083d90f2a287bae8a0
|
|
Change-Id: I31df6c4fd82c6f6d15bbe5228e92e5171cacba51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92410
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Autorecovery should save in the user profile
in the "backup" directory. However, when that directory
did not exist, the temp directory was used instead.
Fix this, and create the requested directory if it did not exist.
Change-Id: Ie298855a740932bc6e6c9f62d4b4bf1b52b80c58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92402
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Ende -> End
Change-Id: Ia3df5ee48e0d61051d99ac93e62c8a6dceafb41d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91218
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
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>
|
|
1. We would like to call CTFontDescriptorCopyLocalizedAttribute function
simply.
We don't need to compare language settings of LibreOffice UI to OS lang-
uage settings.
This comparison was a way to save users from confusion, but it was bad
idea.
Because CTFontDescriptorCopyLocalizedAttribute function before macOS
Catalina returns RFC 3066 bis as a language tag, but LibreOffice and
macOS Catalina uses BCP 47 as a language tag.
CTFontDescriptorCopyLocalizedAttribute function use the language setting
for the operating system, therefore Users will change it if needed.
2. Fix font aliases on macOS Catalina
I added some entries because I notice that those doesn't working with
a Hiragino Sans font alias.
Change-Id: Ie05a96f45cba13a19fcc1b855bd908f397e585a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/81145
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I311e647f08b4d541825e7790d971b98b5b5bfe40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90668
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This reverts commit d8ac55e3e53564aca4b0bade5a5b5cb01b4519b1.
Change-Id: Ib7cf67d5d0b7780dfde9453cdddb8f11ca5d3a6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90542
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I528d0bd7408ab9761de2d6fe8e60a5a521dda4dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89414
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
|
|
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
|
|
...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>
|
|
which acts as a hint to the OS that these files do not
need persistent storage.
If there is sufficient system RAM, these files will never
even hit disk.
Change-Id: I25b83aad67fda58ec39cead8bd1eb038892d3cde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88124
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|