Age | Commit message (Collapse) | Author |
|
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iedd4348f3ea896dc613e0062a1a9cb5904c8bbb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103844
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit da5c289a9cae5d914937f235694fd5b0cb92547f.
Change-Id: Ic6a77ec2cd3b502fb4e94159a0424340850590df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103665
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
probably since...
commit a573b8b21688d9681f4fa129ec37cf89954e9d1c
Date: Sat May 21 16:14:56 2011 -0430
Replace List for std::vector in SfxStringListItem.
Change-Id: I7060b5693ba08fa5f70cc5cb3ae1b7a4722a31a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103408
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...as MSODocumentLockFile::WriteEntryToStream has written it to (i.e.,
always as UTF-16LE, assuming that is actually the right format to use). The
discrepancy between writing and reading the string data appears to be present
ever since the code's introduction in 5db1e20b8b0942dac2d50f3cd34532bb61147020
"Introduce new lockfile handler for MSO like lockfiles".
This caused CppunitTest_svl_lockfiles to fail on (big-endian) s390x Linux with
> svl/qa/unit/lockfiles/test_lockfiles.cxx:578:(anonymous namespace)::LockfileTest::testWordLockFileRT
> equality assertion failed
> - Expected: LockFile Test
> - Actual : 䰀漀挀欀䘀椀氀攀 吀攀猀琀
etc.
Change-Id: I97267aa14a3a926e7fd7bb1d2ce7d2de05d52a64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103238
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Using toUtf8, requiring the OUString to actually contain well-formed data, but
which is likely OK for this test-code--only function, and is also what similar
dumpAsXml functions e.g. in editeng/source/items/textitem.cxx already use.
This appears to have been broken ever since the code's introduction in
553f10c71a2cc92f5f5890e24948f5277e3d2758 "add dumpAsXml() to more pool items",
and it would typically only have written the leading zero or one
(depending on the architecture's endianness) characters. (I ran across it on
big-endian s390x, where CppunitTest_sd_tiledrendering
SdTiledRenderingTest::testTdf104405 failed because of
> Entity: line 2: parser error : Input is not proper UTF-8, indicate encoding !
> Bytes: 0xCF 0x22 0x2F 0x3E
> ation=""/><SfxPoolItem whichId="4017" typeName="13SvxBulletItem" presentation="%
> ^
apparently reported from within libxml2.)
Change-Id: I4b116d3be84098bd8b8a13b6937da70a1ee02c7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103236
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
...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>
|
|
...that had originally started to get introduced with
159a4c3c75e3a7aecbf1656f3254331892098ba7 "tdf#84881: WiP: Fill in more fields of
the TimeStampReq" saying: "Temporarily, dump the TimeStampReq object to a file
for inspection in a DBG_UTIL build."
(I came across this when wondering why such PDFWRITER.cms.data and
PDFWRITER.hash.data files kept popping up in my source/build trees.)
Change-Id: I28beabe912beb112e1c71c8e3b559e161b22849b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102393
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins
|
|
Goes from more than 30s to less than 1s on my pc.
We were getting stuck inside the loop in sw::UndoManager::AddUndoAction,
because the RemoveOldestUndoAction was continually doing nothing because
it was hitting the
if ( IsInListAction()
{
assert(!"SfxUndoManager::RemoveOldestUndoActions: cannot remove a
not-yet-closed list action!");
return;
}
code.
Which means that there is some bug here, but I'm not sure what. We are
deep inside the delete logic at that point, and it doesn't seem
unreasonable to opportunistically delete some of the UNDO list at that
point.
So the real fix is just the conversion from a while loop to an if-check.
Change-Id: Ie2707009dd6574b996421f67d952ab9fdaaaf6aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102378
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...and in turn add OUString::operator = and OUString::operator +=
overloads that take a std::u16string_view. Without making the ctors explicit,
the operator overloads would have caused ambiguities when called with raw
sal_Unicode pointers/non-const arrays, as those can convert to both OUString and
to std::u16string_view.
But the std::u16string_view operator overloads will generally be useful when
changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which
point many existing uses of OUStringLiteral will be replaced with uses of
std::u16string_view.
Implementing this change turned up a need for an operator = overload for
OUStringNumber, which has thus been added. No such need turned up for a
corresponding operator += overload, but which can easily be added when the need
arises.
It also revealed that the operator == overloads between an OUString and a raw
sal_Unicode pointer/non-const array were implemented rather inefficiently,
creating a temporary OUString from the raw argument. Those have been improved.
Preceding commits have already taken care of many dubious or simply unnecessary
implicit uses of the now-explicit OUString ctors. This commit makes explicit
the few remaining reasonable uses. (And in some cases needed to change variable
initialization syntax from using parentheses to using curly braces, to avoid the
most vexing parse issue. And needed to explicitly add OUString ctors from
char16 const[2] string literal lvalues in a conditional expression in
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary
because MSVC apparently still insists on doing array-to-pointer decay there.)
All of this only affects LIBO_INTERNAL_ONLY.
Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...instead of having individual overloads for OUString, OUStringLiteral, and
literal char16_t const[N]. (The variants taking OUString are still needed for
!LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char
const[N] are also left in place.)
This nicely reduces the number of needed overloads. std::u16string_view allows
to pass as arguments:
* OUString
* OUStringLiteral
* OUStringChar (with the necessary conversion added now)
* OUStringNumber
* u"..." char16_t string literals
* u"..."sv std::u16string_view literals
* std::u16string, plain char16_t*, and more
A notable exceptions is OUStringConcat, which now needs to be wrapped in
OUString(...), see the handful of places that needed to be adapted.
One caveat is the treatment of embedded NUL characters, as
std::u16string_view(u"x\0y")
constructs a view of size 1, while only
u"x\0y"sv
constructs a view of size 3 (which matches the old behavior of overloads for
literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16
machinery). See the new checkEmbeddedNul in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx.
The functions that have been changed are generally those that:
* already take a string of determined length, so that using std::u16string_view,
which is always constructed with a determined length, is no pessimization
(e.g., there are operator == overloads taking plain pointers, which do not
need to determine the string length upfront);
* could not benefit from the fact that the passed-in argument is an OUString
(e.g., the corresponding operator = overload can reuse the passed-in
OUString's rtl_uString pData member);
* do not run into overload resolution ambiguity issues, like the comparison
operators would do.
One inconsistency that showed up is that while the original
replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0)
overload takes an optional third fromIndex argument, the existing replaceAll
overloads taking OUStringLiteral and literal char16_t const[N] arguments did
not. Fixing that required a new (LIBO_INTERNAL_ONLY)
rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in
sal/qa/rtl/strings/test_strings_replace.cxx).
Another issue was posed by test code in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the
RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that
certain function calls should not compile (and would compile under
RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to
OUString as arguments). Those problematic "should fail to compile" tests have
been converted into a new CompilerTest_sal_rtl_oustring.
Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ife1c8365298fec713713739073b91d601b459e6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101990
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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: If7791d51d055ad918b54a52bee3f13a79c5468f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101435
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
look for expressions like
!(a && !b)
which can be expanded out
Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie3fe919a7b8296440cd2a670f218147da98f7822
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100653
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Tested-by: Jenkins
|
|
Change-Id: I4f05b6a35010e661ea77f3e4b83302d2ec74d227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100405
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add some API to O*StringLiteral, to make it easier
to use in some places that were using O*String
Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia69fb105c6cc661ac94a360d47655b3faa9d6bb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100618
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie624b324822495192edc65d046945eb92356550b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100192
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Recheck after 7-0 branchoff
Also drop the now unused file include/vcl/field.hxx
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I5ea9e3663fc5d30d725cf18757badb9b9802da18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99675
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Instead move the constants from filter to comphelper and reuse them.
Change-Id: Ib7061e9028ccf6067b4e86f50145c1472c2b01d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98785
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See tdf#74608 for motivation.
Change-Id: If5eec92f2c7707bd0c44b80d352d78a84962ff74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98702
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Ib543223f87e1773645ff6063e7f9f902ff408f33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98701
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7014da07d88861e4f08fb9e1006dccb6fc2ad245
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98406
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
1 .
1 .2
1 . 2
1. 2
. 2
. 2
are not numbers. But
.2
is.
Change-Id: Ie2e0775852e13eee733d0fed3399cbd3d065d9fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97895
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Skip *one* of them under the condition that a month name was
actually recognized.
A horrible implementation of
commit b00fc9462d26083b6d09f72ea44abb1e11546b63
CommitDate: Wed Sep 15 11:54:10 2010 +0200
sc-date-fix.diff: Parse 'june-2007' as June 1 2007 in en-US locales
Change-Id: I0800c4f0b33aa1413bde558d710fe467e4380262
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97903
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
... to accept minutes or seconds >59
Prepare SvNumInputOptions as enum class in case further options
would be needed for anything else.
Change-Id: Ie9ae62adf68f9948e23f55ac32c09a6b992a36e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97784
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: Iedcd2e149690350f0ef131eda5cf61ecfade5c91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97695
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I4f1c0d90fcb7726ceadd72c9cb9f96a57cade67a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97602
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Defer moving around the vector by tagging the last bit in the pointer.
This takes the undo operation from 10s to 8s on my machine.
Also re-organise the fields a little to improve packing.
Also add some design notes
Change-Id: I38fa9156705c00bb9f64e2fc59ea862eba522942
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97424
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Optimize also maDestructedListeners (often just one item). Optimize
also small vectors if there's just one item unsorted. Keep the index
of the first unsorted item in maListeners, so that it's cheap
to find out where the unsorted part starts.
This now improves tdf#132454 to 20s.
Change-Id: I21a69b440c27a2e31e74fd13b9263f54af12e320
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97198
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A common case is just one unsorted item at the end, in that case
it's even more efficient to simply insert it in the right place.
This further improves the tdf#132454 undo operation 36s->27s.
Change-Id: I29db80fb8292e827b655000cddc462cf87cb485d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97088
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
New items are only appended, so it's wasteful to std::sort() the whole
container, just sort the unsorted part (often just one item) and then
merge.
Change-Id: I20b73730700c279e8f844c0b7a392a8f372a22da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97019
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Use Add/Delete decimal to change precision of time and duration
Apply only to 100th second
Change-Id: I2ff1b01db7ee67645511fcf7ea6bf65055e92a8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94765
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
regression from
commit 3581f1d71ae0d431ba28c0f3b7b263ff6212ce7b
optimize SharedStringPool::purge() and fix tests
which results in us potentially de-referencing an already de-allocated
OUString object in the first loop in purge().
So switch to a different strategy, which only needs one data structure,
instead of two.
Change-Id: Iaac6beda48459643afdb7b14ce7d39d68a93339c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95226
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I124dd9be0ca8ede61323dd77b737253c5af99ceb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95570
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
with a slightly dodgy fix.
regression from
commit 3581f1d71ae0d431ba28c0f3b7b263ff6212ce7b
optimize SharedStringPool::purge() and fix tests
It's not ideal - we no longer have a way of purging uppercase keys that
are longer in use.
But that doesn't cost much memory, because we are sharing those strings.
We could potentially identify them with extra book-keeping in either
intern() or purge(), but since this class is performance-sensitive, best
just to sacrifice some space in the map.
Change-Id: I85a469448f5b36b1b6889da60280edd56bbcb083
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95432
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to look for the
x.get() != null
pattern, which can be simplified to
x
I'll do the
x.get() == nullptr
pattern in a separate patch, to reduce the chances of a mistake
Change-Id: I45e0d178e75359857cdf50d712039cb526016555
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which were checking the wrong thing - we don't care
about the input strings to intern(), we care
about which SharedString objects are still alive.
Change-Id: Ia35a173a02a24efb335268dcae4078a956d11098
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95177
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
mostly to catch stuff from the flatten work, but I think this looks good
in general
Change-Id: I7be5b7bcf1f3d9f980c748ba20793965cef957e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92493
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Remapping NatNum-DBNum in Korean for compatibility tdf#130193
Unlike Japanese and Chinese[Simplified, Traditional] environment on Excel, In Korean Situation, Excel exist DBNum1~4.
I checked DBNum1~4 series on Excel 2016 in Korean Environment.
DBNum1 1234567890 一十二億三千四百五十六万七千八百九十
DBNum2 1234567890 壹拾貳億參阡四百伍拾六萬七阡八百九拾
DBNum3 1234567890 十2億3千4百5十6万7千8百9十
DBNum4 1234567890 일십이억삼천사백오십육만칠천팔백구십
Also, I checked Korean Number to Strings on LibreOffice.
[natnum1] 1234567890 一二三四五六七八九〇
[natnum2] 1234567890 壹貳參四伍六七八九零
[natnum3] 1234567890 1234567890
[natnum4] 1234567890 一十二億三千四百五十六万七千八百九十
[natnum5] 1234567890 壹拾貳億參阡四佰伍拾六萬七阡八佰九拾
[natnum6] 1234567890 1십2억3천4백5십6만7천8백9십
[natnum7] 1234567890 十二億三千四百五十六万七千八百九十
[natnum8] 1234567890 拾貳億參阡四佰伍拾六萬七阡八佰九拾
[natnum9] 1234567890 일이삼사오육칠팔구영
[natnum10] 1234567890 일십이억삼천사백오십육만칠천팔백구십
[natnum11] 1234567890 십이억삼천사백오십육만칠천팔백구십
I also checked Korean billion units test.
[natnum1] 123456789012 一二三四五六七八九〇一二
[natnum2] 123456789012 壹貳參四五六七八九零壹貳
[natnum3] 123456789012 123456789012
[natnum4] 123456789012 一千二百三十四億五千六百七十八万九千一十二
[natnum5] 123456789012 壹仟貳佰參拾四億五仟六佰七拾八萬九仟壹拾貳
[natnum6] 123456789012 1천2백3십4억5천6백7십8만9천1십2
[natnum7] 123456789012 千二百三十四億五千六百七十八万九千十二
[natnum8] 123456789012 仟貳佰參拾四億五仟六佰七拾八萬九仟拾貳
[natnum9] 123456789012 일이삼사오육칠팔구영일이
[natnum10] 123456789012 일천이백삼십사억오천육백칠십팔만구천일십이
[natnum11] 123456789012 천이백삼십사억오천육백칠십팔만구천십이
As a result,
1. from DBNum to NatNum (import):
- DBNum1 -> NatNum4 (Korean Hanja text 한자숫자)
- DBNum2 -> NatNum5 (Korean Upper Hanja text 갖은자)
- DBNum3 -> NatNum6 (fullwidth Arabic digits with Korean hanja unit of Numbering)
- DBNum4 -> NatNum10 (Korean Hangul text)
I found the Bug for NatNum6 (I'll change Korean Hangul to Hanja for compatibility)
2. From NatNum to DBNum
- NatNum1 -> DBNum1
- NatNum2 -> DBNum2
- NatNum3 -> DBNum3
- NatNum4 -> DBNum1
- NatNum5 -> DBNum2
- NatNum6 -> DBNum3
- NatNum7 -> DBNum1
- NatNum8 -> DBNum2
- NatNum9 -> DBNum4
- NatNum10 -> DBNum4
- NatNum11 -> DBNum4
By the way, I change test cases for Korean.
It is included in svl/qa/unit/svl.cxx
It solves the issue tdf#130140
Also, It related the issue tdf#130077
Change-Id: Idb7f3defc5f19e3edc4c179b0a081d2abe8ee3a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94747
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
remap NatNum - DBNum in Japanese/Chinese to improve
Excel interoprability
from DBNum to NatNum (import) in ja/zh:
- DBNum1 -> NatNum4 (modern long Kanji text)
- DBNum2 -> NatNum5 (traditional long Kanji text)
- DBNum3 -> NatNum3 (fullwidth Arabic digits)
from NatNum to DBNum (export) in ja:
- NatNum1 -> DBNum1
- NatNum2 -> DBNum2
- NatNum3 -> DBNum3
- NatNum4 -> DBNum1
- NatNum5 -> DBNum2
- NatNum6 -> DBNum3
- NatNum7 -> DBNum1
- NatNum8 -> DBNum2
- NatNum9 -> (DBNum0, as Arabic)
in zh, nothing change about export.
It also partially solves the issue tdf#130140
(about Japanese, not Korean)
To do this, more data-drivened MapDBNumToNatNum() and
MapNatNumToDBNum() in svl/source/numbers/zformat.cxx
By mapping "NatNum - DBNum" to a table using map and array, it
makes the specification for each language more understandable
The new test cases are also included in svl/qa/unit/svl.cxx
Change-Id: I34a70d970ef2e46c1b3db5db1c397ab89c056191
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94376
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
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>
|