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>
...recently introduced with 52a49f9e48
"static_assert that O[U]StringLiteral are layout compatible with rtl_[u]String"
Change-Id: Ie89e92aa4230329aa582c4211c2001117d2287b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103138
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as was suggested by Mike Kaganski in a comment at
<https://gerrit.libreoffice.org/c/core/+/102222/10#
message-aa8bcf42f04686766440e2848c7d1f76f474f2f8> "Turn OUStringLiteral into a
consteval'ed, static-refcound rtl_uString". Doing so revealed that at least
lopglugin:unusedmember needs to handle InjectedClassNameType as an alternative
to RecordType in at least one place. (More places across compilerplugins might
benefit from handling InjectedClassNameType too, but which did not lead to
assertion failures for now and should be addressed in follow-up issues.)
Change-Id: Icdb8b069324b5ce5f3c7c6b92989379ccb67fc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103125
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<https://gerrit.libreoffice.org/c/core/+/101829>
"Make std::u16string_view -> OUString construction explicit" (which has
meanwhile been abandoned) had intended to make the OUString(std::u16string_view)
ctor explicit, mostly not for the rationale given in the commit message there
(it being "a rather expensive operation"), but rather to avoid anticipated
ambiguity issues when introducing e6dfaf9f44 "Turn
OUStringLiteral into a consteval'ed, static-refcound rtl_uString"---but which
has ultimately been added in a form that did not give rise to such ambiguity
issues after all.
4b9e440c51 "Turn OStringLiteral into a
consteval'ed, static-refcound rtl_String" had added the
OString(std::string_view) ctor as explicit to match the corresponding explicit
OUString(std::u16string_view) from the above
<https://gerrit.libreoffice.org/c/core/+/101829>. But as that has now been
abandoned, there is no good reason to keep this ctor explicit, either.
Change-Id: I05742de5f3992ad5995149631bf8d55c8d448387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103124
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "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>
...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 4b9e440c51
"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
a1570b6052 "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
4b9e440c51 "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>
...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>
...introduced with 2e21240f23 "Goodbye
O[U]StringView, welcome O[U]String::Concat". Thanks to Mike for spotting them!
Change-Id: Ic401c564eac03a34184204f09cb8d0cb6be4e6e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101689
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 33ecd0d5c4 "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>
0c8fa58a2d "Support ConstCharArrayDetector also
for UTF-16 arrays" had introduced those LIBO_INTERNAL_ONLY ctor and operator ==
overloads, but they never got called because the existing 'sal_Unicode const *'
overloads always won.
(The other function overloads introduced with
0c8fa58a2d should be unproblematic, as they do not
have any 'sal_Unicode const *' overload counterparts.)
Also fix the resulting loplugin:elidestringvar and loplugin:stringconstant
fallout. For one, those plugins look at the actual ctor overloads being used,
so had missed those cases that accidentally had used an unexpected overload.
And for another, the heuristic the plugins used to detect the
ConstCharArrayDetector overloads turned out to be too simplistic now and would
have started to cause false positives.
Change-Id: I4426890979fb832d53f391c7e1b62bc1ad501a65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101582
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which in turn should be a LIBO_INTERNAL_ONLY feature, so confine all relevant
declarations accordingly
Change-Id: I7545eadad6f097d0ee905583b1610631c92f1858
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101373
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Apparently typos in 0c8fa58a2d "Support
ConstCharArrayDetector also for UTF-16 arrays" that went unnoticed as for a
const OUString s,
s == u"..."
could still pick the
bool operator ==(OUString const &, sal_Unicode const *)
overload.
Change-Id: I61344ef2912fffca3cccf375e2e4c2be9beca604
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101377
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit e287fde52f "Silence bogus
-Wstringop-overflow with GCC trunk towards GCC 10", as that workaround, which
happened to work for some revisions of GCC trunk towards GCC 10, no longer works
for GCC 10 release candidates, see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893#c9> "[10 Regression]
Unhelpful -Wstringop-overflow warning for a trailing one-element array".
(Using -Wstringop-overflow=1 instead of the -Wstringop-overflow=2 default would
have still caused bogus warnings, requiring -Wno-stringop-overflow.)
Change-Id: I9b7342748c18da32f509b4a0e0653aede8447657
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93499
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
by 10%, by avoiding an OUString construction in a hot path
through
XMLTextColumnContext_Impl::XMLTextColumnContext_Impl
-> sax::Convert::convertNumber
Also changed XMLTextAnimationStepPropertyHdl::importXML
to take advantage of the modified convertNumber passing
convention.
Change-Id: I4e5503dbb094c88a09af8b6dc8c22b6c53f9eb75
Reviewed-on: https://gerrit.libreoffice.org/81726
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...similar to OUStringChar, to be used in string concatenation expressions. And
enable the corresponding loplugin:stringadd check, and fix its findings.
Change-Id: I35ebb2253ba82bda6c98ae6ebd2ad4f27cf9abf9
Reviewed-on: https://gerrit.libreoffice.org/81456
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so forbid anything else, to avoid issues like the one described in
766cdd869d "This code wants to add the numeric
SvxRotateMode value". Some remaining places that apparently do want to convert
some numeric value to sal_Unicode have been augmented with an explicit cast.
Change-Id: I6200a84e250e697bc88694bd71142ca1d9a13651
Reviewed-on: https://gerrit.libreoffice.org/81132
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and extend O*StringView to have a constructor that takes a pointer and a
length
Change-Id: I6120e96280f030757e855a6596efdae438b7e1e8
Reviewed-on: https://gerrit.libreoffice.org/80872
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...(which got introduced with 9b5dad13b5
"loplugin:stringadd look for unnecessary temporaries", and had reportedly
broken CppunitTest_sc_ucalc on tml's Windows build by hitting the
"strlen( str ) == N - 1" assert at include/rtl/string.hxx:1867), by introducing
rtl::OStringView (and rtl::OUStringView, for consistency).
Change-Id: I766b600274302ded66a6bffc91be189b20ed1ac3
Reviewed-on: https://gerrit.libreoffice.org/80778
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to find matches of
... << s.getStr()
(for the rtl string classes) that can be written as just
... << s
Some notes:
* The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in
desktop/source/app/crashreport.cxx (even though that would also be done
internally by the "<< OUString" operator) to clarify that these values are
written out as UTF-8 (and not as what that operator << happens to use, which
just also happens to be UTF-8).
* OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now.
* Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in
lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx.
* The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just
go, too.
Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136
Reviewed-on: https://gerrit.libreoffice.org/80762
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which defeat the *StringConcat optimisation.
Also make StringConcat conversions treat a nullptr as an empty string,
to match the O*String(char*) constructors.
Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b
Reviewed-on: https://gerrit.libreoffice.org/80724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that was present ever since d87f5d3087
"support for fast O(U)String concatenation using operator+" but was likely a
typo/thinko
Change-Id: I0e56166d95f447a26dba9b456255b4ed339f1e2f
Reviewed-on: https://gerrit.libreoffice.org/80668
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
(and #include's of it in include/rtl/*.hxx are already guarded with
LIBO_INTERNAL_ONLY)
Change-Id: I9224f71a244a69ef69406ea3a5879b66b3cae3a3
Reviewed-on: https://gerrit.libreoffice.org/80666
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
so we can construct efficient expressions when we have pointers to
unicode data
Also lightly reformat a couple of the older helpers to make it easier to
compare the different helpers.
Change-Id: Ib8a4227714e9218512b6871d3285e4e2703bec3b
Reviewed-on: https://gerrit.libreoffice.org/80639
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel