Age | Commit message (Collapse) | Author |
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic63d3c0ebd1e58d7bab5b0fd6313cabddc16eb98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104517
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5681249808cf623d3b7df09988f285268ea8d85f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104255
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
instead of a mix of unsigned and sal_uInt16.
Change-Id: Ice56d58d22856daa6645577610368ba19a849176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104076
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If7fbb25037343e18081a8ee7064840d75e9a45a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104010
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaa6c6eac15cb73fc2a76ba1c5241297c94d297cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103839
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>
|
|
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
|
|
We must link nss statically, including the three dylibs that normally
are loaded at run-time, because including bare dylibs in an iOS appp
on the App Store is not OK. See
https://developer.apple.com/forums/thread/125796 .
For linking the softokn3 library statically, NSS already had code,
behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros:
NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the
nssckbi library.
Turn off parallelism for the sub-make building nss. There seems to be
race conditions or something when running simultaneous instances of
the nsinstall.py script or the nsinstall program in nss (used when
building nss for the build platform).
When cross-compiling from macOS, use python3 to run the nsinstall.py
script, as it is Python 3.
Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218
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>
|
|
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@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: I786548bef39fa711aabcff32b592b3fdc4a6f9fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@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>
|
|
Change-Id: I6a300169d33bdc36e4c7e720a7afc336a86eea68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100962
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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: I6b3b6ef1530a192f4b6bf87aa9688687063683ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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: 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>
|
|
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>
|