Age | Commit message (Collapse) | Author | Files | Lines |
|
The bug mentioned happens due to a system-dependent
difference: Unx-systems allow files to be opened for
write multiple times while our windows implementation
until now did prevent that.
For that reason an embedded OLE which is still opened
in the same LO instance behaves wrong/strange - the
e.g. changed size cannot be written (to the file).
Since we already have unx-like handling and in that
scenario useful sync has to be done anyways, no new
scenario will be created. Only Windows implemenation
will change to behave closer to unx-like behaviour,
I already test-built that on gerrit to make sure all
tests for Windows work as before.
I thought about this for quite some time, but see no
too big risk. For thoughts/discussion please refer
to the task.
Change-Id: I8dbfd70c2f69d0a013f445e152e597f37fa6ecc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112237
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
(cherry picked from commit 2b4cd99d3360ccffb9829a02412824864d045753)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112427
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
I didn't take clock resolution into account when created the test,
and it failed for me occasionally because the value was slightly
less than expected.
The typical system tick resolution is documented at
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers
Change-Id: Ie48b10d15b14f9ac7d292a2cc9916bcbfff44b6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111946
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit eef43192d4c7b2867638c54a2ac31adfc26476c7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112076
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Debugging the test case from the latter bug report shows that indeed
the call to OleGetClipboard may fail first time, as jasonkres had
suspected in the former bug. So follow the suggestion in tdf#116983,
and retry the failing calls several times in case of failure.
Many thanks to Telesto for preparing a clear bug report with reliable
test case.
Co-authored-by: jasonkres
Change-Id: Ib3c497da830bc5faac586bcfe1eededa54bfa117
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111825
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit cf1c835e8016f8f1eefea6d625a913c0ac343a63)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112075
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I512cedcd46f829b97b62a57d90d5a4a81d024d66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110598
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
This is a combination of 3 commits.
Add sal_uInt64 fields to sal_math_Double
We may need them later, and at least don't have a confusing
inf_parts or nan_parts struct name but just parts as well.
Ife0cf279c47d2815aa2a1483223397b147e9d776
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107924
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Replace log2() call with parts.exponent-1023, tdf#138360 follow-up
... to save some cycles as we anyway need only the integer value
of the exponent and even exactly this value for the number of
possible decimals.
I8d462f53cadde6a95d57d1342d8487fbfa001ae9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107928
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Check intermediate for not to be rounded value, tdf#138360 follow-up
I98cc25267e7a10c34179bab50d19f49436e1c48c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107929
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Change-Id: I98cc25267e7a10c34179bab50d19f49436e1c48c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107931
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Similar to commit 5abb1890ffafe5a2212076208a1c6e226f1ffa4e for
rtl_math_round() use the reciprocal value in an inverse operation
for negative exponents to not use the inexact 1e-1
0.10000000000000001 and so on factors.
Change-Id: I05b852e06f2c31d6e0ce622b07277a81a5690833
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107172
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 520949f17a91c531ea0c8b3856ffcf3c7ac8a3b2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107195
|
|
Ditch mostly but not always working correction value and use
approxFloor() instead which yields better results. With this we
now have one single place approxValue() in case more fine grained
tuning is needed.
Unfortunately all numeric spreadsheet function tests use ROUND()
in a manner such that they mostly blindly do a ROUND(...;12)
regardless of magnitude, sometimes effectively rounding to the
14th significant digit that may fail in cases like for
14.2040730851385
^
where the constant (rounded) value is stored as is but the
calculated value is
14.204073085138471
and the old round() yielded
14.204073085139 for both but the new round() more correctly
results in
14.204073085139 and
14.204073085138
so the spreadsheet test case sources had to be changed to
ROUND(...;11) in such places.
Change-Id: I211bb868a4f4dc9e68f4c7dcc2a187b5e175416f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107135
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit deb119e415213716a76b9b489a700949c031c6fe)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107101
|
|
Change-Id: Ic436d3e9f0c93cb36c5e4377519f2aeb6b7fbd5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107034
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit d8e0b1c81ffa16be8aae2231bcd3c02e8c01cf88)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107025
|
|
Change-Id: Ica25747a26d6c2637c46808d1b73aeeed6e1df37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107001
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 49aff144c72a5258cf2ca392a0cfb7a31fb86819)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107017
|
|
Decimal negative exponents (powers) are imprecise
1e-1 0.10000000000000001
1e-2 0.01
1e-3 0.001
1e-4 0.0001
1e-5 1.0000000000000001e-05
1e-6 9.9999999999999995e-07
1e-7 9.9999999999999995e-08
1e-8 1e-08
1e-9 1.0000000000000001e-09
1e-10 1e-10
1e-11 9.9999999999999994e-12
1e-12 9.9999999999999998e-13
1e-13 1e-13
1e-14 1e-14
1e-15 1.0000000000000001e-15
1e-16 9.9999999999999998e-17
1e-17 1.0000000000000001e-17
1e-18 1.0000000000000001e-18
1e-19 9.9999999999999998e-20
1e-20 9.9999999999999995e-21
so use the positive exponents instead and swap multiplication and
division when scaling and scaling back the value, which multiplies
the rounded value with a precise integer instead of dividing it by
an imprecise fraction.
For a large (absolute) value check if it is roundable to the
desired decimals at all with the binade's distance precision gap
and if not then diminish the decimals parameter. This prevents
possible inaccuracies due to overly scaling the value.
Change-Id: I41a113078031a552cf98d72f8cb2b10bdc88dea4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106830
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 5abb1890ffafe5a2212076208a1c6e226f1ffa4e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106814
|
|
This is a combination of 2 commits.
Consistently use RTL_CONSTASCII_LENGTH(), tdf#136272 follow-up
The mix with SAL_N_ELEMENTS() was confusing and even wrong in one
case.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106764
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 1a0f9a9c56e7b7952b813b3efd34f9be6c853957)
Fix comment
I2ae6e3cadc0f182c4798e5d33b0c7f07fbcbbff6
(cherry picked from commit b8404ae521a9c2d183d4e076a7884627ba353e4b)
Change-Id: Ife73342b0efc01ed4e76e217d372fc32500c9b2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106782
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
... and the 4 subsequent nextafters to appropriate strings.
An interim workaround to not write the out-of-range string
1.79769313486232e+308 until we have a proper rounding.
Change-Id: I5f98a7f0a8e0421fd024a8cc37cc6f3a198d02d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106717
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 4713c19e2b79341dc27e66d4c6449497db1e73d8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106685
|
|
This does not solve writing the badly rounded value, which still
has to be fixed, but at least be able to read/convert it back as
double max value.
This is not even used in the bug scenario because the "fake"
condition in that number format is discarded anyway because it was
only written to satisfy ODF, but it helps in case a
1.7976931348623157e+308 value was entered/used on purpose.
Change-Id: I413dd93d5a3c4df609fd42a3133d6d82c34afff0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106586
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit ee2cc952eeb5385ee37485c822d7ad7abd8fb989)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106526
|
|
...that take a pointer and a length, and where it should be OK that the pointer
is null if the length is zero. Those rtl_uString_* functions are targets of
OUString member functions that take std::[u16]string_view arguments, and
19926ed35ebb623fc896942b1f232b83edf1fc1e "loplugin:stringview: Flag empty string
converted to string view" (which changed some call sites to pass in default-
constructed std::[u16]string_view, for which data() returns null) revealed that
those rtl_uString_* functions were not prepared for such input.
(The guardings of memcpy are necessary because memcpy still requires its pointer
arguments to be non-null, even if the corresponding length is zero.)
The new sal/qa/rtl/strings/test_strings_defaultstringview.cxx systematically
tests all O[U]String[Buffer] member functions taking std::[u16]string_view
arguments. It revealed one further issue in
IMPL_RTL_STRNAME(compare_WithLength), where UBSan reported a
nullptr-with-nonzero-offset
> sal/rtl/strtmpl.cxx:149:9: runtime error: applying non-zero offset 18446744073709551614 to null pointer
Also, rtl_uString_newReplaceFirstUtf16LUtf16L was found to lack a check for its
`from` argument to be non-null.
Change-Id: I6a7a712570f7d1e8d52097208c8a43a5a24797af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106295
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I04a773e8fd565f57dc0eb887fb4714b6edbb35e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105699
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
This allows to test the actual type, not something unrelated
Change-Id: I82d0714f6355fc5ae7bd3205af3472a43f1f1051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105998
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
in favour of the more widely used, and better optimised, operator+
Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar]
> aXmlWriter.content(sPdfConformance);
> ^~~~~~~~~~~~~~~
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar]
> OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B";
> ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)
Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Protect against callers using for example rtl_math_StringFormat_F
with rtl_math_DecimalPlaces_Max in worst case..
Change-Id: I9f143df6ae67b22e7732547c0f7a53b498caf2b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104472
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
isn't available there.
While here, change the #ifdef check from __FreeBSD_kernel_ to __FreeBSD__, because pthreads API is userspace (read, belongs to libc).
Change-Id: I83e76b5502a6dfa1be5d3598eb1367f25815396e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104098
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Iee5e7d3e91b6da5eb6c87d8d3547e0cd65742db7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103945
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I2ce95de07b8e0952a1e778e65940b30597396aa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103949
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It passed "make check" on Linux
Change-Id: I61781bccc365630f15a9baef5224012b0775edbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103446
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
-visual: so that the human eye can easily find it
-at start: to identify the last test if it ends abruptly
-no spaces: easy scripting | grep RUN | awk '{print $2}'
A visually unique, eye-catching start banner
will be helpful when browsing through logs,
or when adding asserts and running a make sw.check.
[I frequently look for existing unit tests that match
a certain condition in the 15 ooxmlexport tests.]
Previously, the tests ran in the order that they existed
in the file. So if one asserted/crashed in the middle of
the run, you could easily guess which test it was
by finding the name of the test that just finished OK.
However, since
2f2246d22e2a8ccbc1dc3e6f5243734a61edf270
Author: Stephan Bergmann on Sat Aug 8 12:00:23 2020
external/cppunit: Run tests in deterministic order
the tests are sorted by name and run in
alphabetical order - which is not at all obvious or
intuitive. It certainly makes it harder to guess
what the next alphabetical name will be.
P.S. For consistency, I considered adding [____DONE_]
as well, but existing tooling might search for
"finished in:" and grab the first string (the test name)
so I don't want to break anything doing that.
Change-Id: I5521e681cd9f8304842290680f0389256fe3fe43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103268
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ibb996a3440a272405531c6d3cda0faa1d8c72ec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103260
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
do more like
commit 121771e37f7e2de41cd5643475861062bf25627b
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
At least on Windows, e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn
OUStringLiteral into a consteval'ed, static-refcound rtl_uString" caused
CppunitTest_sc_tablesheetsobj to fail at exit, when the
static OUString aCacheName
in ScDocument::GetTable (sc/source/core/data/document.cxx) is destroyed but
references
constexpr OUStringLiteral gaSrcSheetName(u"SheetToCopy")
from test/source/sheet/xspreadsheets2.cxx in Library_subsequenttest, referenced
(only) by the CppunitTest_sc_tablesheetsobj library, and both those libraries
had already been unloaded from memory.
Change-Id: Icea85019611fbaec3603f37b234e9e6fe3502961
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103103
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@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>
|
|
+ remove sal_Char check on compilerplugins
Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9
Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8a8108ae970613559a68d996dddcee485ddc052f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102235
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
...and fix the detected fallout.
That ctor only started to get used recently with
a1570b6052ae9c9349282027c9007b071589bce6 "Make the OUString
ConstCharArrayDetector::TypeUtf16 overloads are actually used", but it turns out
that that also gave rise to that ctor being picked in error. To better guard
against such erroneous uses, make that ctor assert that the given array does not
contain embedded NUL characters, see the new
sal/qa/rtl/strings/nonconstarray.cxx tests.
The one place where that assert would fire during `make check` is fixed now in
SwWW8ImplReader::ImportDopTypography.
That assert would also fire for tow OUStringLiteral-related tests in the
recently added test::oustring::StringLiterals::checkEmbeddedNul, so drop those
for how. They cna presumably be added back (with reversed logic values) when
OUStringLiteral is changed similarly to how OStringLiteral was changed in
4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a
consteval'ed, static-refcound rtl_String".
Change-Id: I6056244003a20f77ba0d953538d25edcbd562211
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102063
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>
|
|
...introduced with b5ad72bbfca85946e352b56d9d2ee5eb71cd2132 "Replace
VALID_CONVERSION macro with function". (VALID_CONVERSION of a lambda was
trivially false, as neither OUString nor OUStringBuffer have a ctor taking a
lambda, anyway.)
Change-Id: I1d4f2de0e1b1973d8680f53e03dbbb3d939fcc03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101982
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...from which an OString can cheaply be instantiated.
The one downside is that OStringLiteral 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 containers 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::string_view, without loss of efficiency
compared to the original OStringLiteral, and without loss of expressivity (esp.
with the newly introduced OString(std::string_view) ctor).
The new OStringLiteral 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 OStringLiteral is in all cases where an
object that shall itself not be an OString (e.g., because it shall be a
global static variable for which the OString ctor/dtor would be detrimental at
library load/unload) must be converted to an OString instance in at least one
place. Other string literal abstractions could use std::string_view (or just
plain char const[N]), but interestingly OStringLiteral might be more efficient
than constexpr std::string_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.
sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC
bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". Those places, as
well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx
and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been
replaced with OString::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).
This change also revealed a bug in at least recent Clang 12 trunk
CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least
in some calls from loplugin code (for which it can be fixed for now in the
existing compat::getSubStringAsWritten).
A similar commit for OUStringLiteral is planned, too.
Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
_CRT_NON_CONFORMING_SWPRINTFS is unconditionally defined in
solenv/gbuild/platform/com_MSC_defs.mk, anyway
Change-Id: I43eabc460dfe3ec9e86ec255f0b100eb22166864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
O[U]StringView had an odd mixture of uses. For one, it was used like
std::[u16]string_view, for which directly using the latter std types is clearly
the better alternative. For another, it was used in concatenation sequences,
when neither of the two leading terms were of our rtl string-related types.
For that second use case introduce O[U]String::Concat (as std::[u16]string_view
can obviously not be used, those not being one of our rtl string-related types).
Also, O[U]StringLiteral is occasionally used for this, but the planned changes
outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral
from char[] to char16_t[]" commit message will make that no longer work, so
O[U]String::Concat will be the preferred solution in such use cases going
forward, too.
O[U]StringView was also occasionally used to include O[U]StringBuffer values in
concatenation sequences, for which a more obvious alternative is to make
O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat
machinery.
Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I473956d570feac508e52a3e52cc26cc154f4dc56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101627
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
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: I024c7437e876459e22a6f541405b87ac13e7dc99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101135
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idca54798ab5ad464f8a641eb6250cb20aa2147ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100840
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
And while at it, merge the change from e2bd5afd726abd5df438b6b821416bd7cf496e4d
"Make the C++/UNO bridge work to some extent on macOS on arm64" into the
existing code in a better way, reviving the assertion that openMax will be non-
negative when entering the loop.
Change-Id: I4b4e173a79ae6a0bbbf07df87d46761e86f460c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100841
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
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: I6560756eb63856a22b43e3e65a7b7843cd2d5376
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use the same code as for Linux on aarch64, with minor
additional hacks. But that will not actually work in all cases, as
there are slight differences in the ABI. See
https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
Thus we can drop the use of the lo_mobile_throwException() hack that
was very temporarily used.
The run-time code generation requires use of a new API on macOS to
work: See the use of pthread_jit_write_protect_np() in
bridges/source/cpp_uno/shared/vtablefactory.cxx.
For some reason, with the Xcode 12 betas, when compiling for
arm64-apple-macos, the symbols for the type_infos for the UNO
exception types (_ZTIN3com3sun4star3uno16RuntimeExceptionE etc) end up
as "weak private external" in the object file, as displayed by "nm -f
darwin". We try to look them up with dlsym(), but that then fails. So
use a gross hack: Introduce separate real variables that point to
these typeinfos, and look up and dereference them instead. If this
hack ends up needing to be permanent, instead of having a manually
edited set of such pointer variables, we should teach codemaker to
generate corresponding functions, and look up and invoke them to get
the std::type_info pointer.
When compiling for x86_64-apple-macos, the type_info symbols end up as
"weak external" which is fine.
With this, LibreOffice starts and seems to work to some extent, and
many unit tests succeed.
Change-Id: I05f46a122a51ade1ac7dccd57cb90e594547740e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100408
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
...plus ensuing loplugin:unnecessaryparen in vcl/source/treelist/transfer.cxx
Change-Id: I1abf2e0c589c2c124399c1337f5dd703ee7d04a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100094
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie6dc22edbcfdf05ab8d7d668cb7cc33b5b747995
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100100
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I221351bdc43b48e714acca89bc84db007258299e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99115
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|