Only check whether LIBO_INTERNAL_ONLY is defined or not. Don't check its value.
If undefined, its value will default to 0, but checking the value will
cause a warning that will be treated as an error if you compile with
-Werror, as you should.
Change-Id: I1d9e4569a016d2e6dbaa9d612071a5528ff1902e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146066
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
shaves 4% off the save time here.
We don't need to do this - either the old rtl_uString will be
overwritten in the source object, or it will be destructed, either way,
re-initialising it is a waste of time.
Change-Id: I47becb17de1e47f2a26c2ac4497e769e13523115
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143403
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
After 6d6a143913 "Address some of the sprintf in
vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23
compiler that implements
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" started to fail with something like
> vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString'
> return aDefaultGlyphName;
> ^~~~~~~~~~~~~~~~~
[...]
> include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument
> OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() )
> ^
etc. So I figured there should be something better than
433ab39b21 "Adapt implicit OString return value
construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts
in comphelper/source/xml/xmltools.cxx and
sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in
a way that keeps code that works up to C++20 also working in C++23.
(The fix is only relevant for non-explicit constructors that involve
NonConstCharArrayDetector and non-const lvalue references, not for other
functions involving those. OUString has a similar constructor but which is
explicit, and OUStringBuffer doesn't have any similar constructors at all, so
this only affects OString and OStringBuffer constructors.)
Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...(which cause -Werror,-Wdeprecated-declarations with macOS 13 SDK), by making
CffSubsetterContext::getString, and in turn CffSubsetterContext::getGlyphName,
return OString. Which in turn required adding rtl::OStringConstExpr and
OString::unacquired counterparts of rtl/ustring.hxx functionality to
rtl/string.hxx.
(It's not quite clear to me whether the nMaxLen clipping in
CffSubsetterContext::getString was only there to avoid overflow of the--
somewhat arbitrarily sized?---static aNameBuf, so could go now, or rather served
as a more general safety measure to not read past the mpReadPtr buffer end and
should thus remain. Hence, I added a TODO comment for now.)
Change-Id: I473d5a54a4be5b02917e197391e4f0982dcf690c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142412
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...when shoehorning a std::size_t value into sal_Int32, to not suppress
potential warnings from tools like -fsanitize=implicit-signed-integer-truncation
and -fsanitize=implicit-integer-sign-change
Change-Id: I610410f7cd69769c3721b2019e16b4c9f214ad81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142407
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...from ustring.hxx, in preparation of using its OUStringConstExpr as a
blueprint for a corresponding OStringConstExpr in string.hxx
Change-Id: I3bf89133e9308dd56e2041a2a5ebb68145fdd0e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In the process, drop ToStringHelper::allowO(U)StringConcat, because
we can deduce this information from ToStringHelper's addData itself.
To do that, addData was converted to ToStringHelper::operator(),
which allows to use std::is_invocable_v on the helper class.
Change-Id: Ic77878ca0ff65ada8c0a942191bc11de15b9ad2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141254
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...as referenced e.g. at
<https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/aa975345(v=vs.71)>
"Code Pages Supported by Visual FoxPro". That source lists those two encodings
with "code page" values 895 and 620, resp. (which might be what we call "Windows
code pages" in include/rtl/tencinfo.h) and "code page identifier" values 0x68
and 0x69, reps. (which might be what we call "Windows charsets" in
include/rtl/tencinfo.h. But I deliberately left these two new
RTL_TEXTENCODING_* values without any mappings to such Windows codepages etc.,
as I didn't find any authoritative sources. What I used is the information
available at <https://en.wikipedia.org/wiki/Kamenick%C3%BD_encoding> and
<https://en.wikipedia.org/wiki/Mazovia_encoding>.
(And while at it, I also updated the instructions what to do "Whenever some
encoding is added here" in include/rtl/textenc.h.)
This commit is building on some prior, abandoned work by Julien Nabet at
<https://gerrit.libreoffice.org/c/core/+/139819> "tdf#150877: DBF Mazovia
encoding (0x69)".
Change-Id: Iae8af4ebab8915411499ae7ef951339b335aa857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140014
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These functions take the string length instead, so may take
non-NULL-terminated strings.
Change-Id: I21dbfd97adec197ba52ae5f9e01340b44689805b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138658
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
which gives better performance when putting strings into hashed
containers that expect good key distribution.
This hash implementation is the same one that Java uses.
Change-Id: Iae5cf3cd27309856acfa51781295f2e56c8e77db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138574
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 59059d00c2, as it effectively
did nothing, as rvalues can bind to `const &` just fine.
<https://gerrit.libreoffice.org/c/core/+/133747> "Acutally do prevent using
O[U]String::subView on temporaties" would have fixed that, but (a) it didn't
find any actual mis-uses and (b) rather would have required a handful of
legitimate cases to be dressed up with o3tl::temporary now, so is arguably not
worth it.
Change-Id: I923d0db2646dc8ea66d1b2a8b709ee2cd7a60ed4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to make those char class array initializations more readable. (Making the
corresponding variables constexpr is mostly done so that failures in the
provided `unencoded` arguments, like non-ASCII characters or duplicate
character typos, would lead to compile-time errors also for !HAVE_CPP_CONSTEVAL.
And assigning to a sal_Bool std::array needs another hack to avoid false
loplugin:implicitboolconversion warnings.)
Change-Id: Ieb8827f69f55f1212a9428817d5331fcb18ef1d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For !LIBO_INTERNAL_ONLY, go back to the state before
d91d98a536 "fix gcc-4.0.1 and/or 32bit build for
string literals" of having just a sal_Int32 overload. (For !LIBO_INTERNAL_ONLY,
the current state was confusing, as the existence of further overloads depended
on __cplusplus >= 201103L.)
And for LIBO_INTERNAL_ONLY:
* Have overloads for all integral types, with an assert checking that they do
not use out-of-bounds length arguments. (The std::make_unsigned_t dance in
the assert is needed to avoid signed/unsigned mismatch warnings as seen at
least with MSVC.) This removes the need for explicitly casting arguments that
are larger than (unsigned) int. (And I cleaned up two such places that I had
become aware of with the abandoned previous attempt
<https://gerrit.libreoffice.org/c/core/+/132825> "Let O[U]StringBuffer ctors
take sal_Int32 length parameters"; there may be more places to clean up,
though.)
* Have deleted overloads for all integral types that are not actually integer
types. (This excludes signed char and unsigned char, as at least
> OUStringBuffer aBuf( rToken.GetByte());
in ScTokenConversion::ConvertToTokenSequence in
sc/source/ui/unoobj/tokenuno.cxx does a legitimate call with an argument of
type sal_Int8 aka signed char.)
Change-Id: I2df77429f25b74f19cc3de5064e6fd982e87b05e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132951
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Regression introduced into LIBO_INTERNAL_ONLY code with
1da6908173 "add string_view variants of methods to
O[U]StringBuffer".
And add some tests. Assigning an OStringChar to an OStringBuffer also uses the
std::string_view assignment operator, so also test that with testOStringChar,
even though there it is relatively likely that the OStringChar temporary is
followed by null bytes, which could make the test happen to erroneously succeed.
But at least tools like ASan or Valgrind could catch that. On the other hand,
assigning an OUStringChar to an OUStringBuffer does not use the
std::u16string_view assignment operator (and rather uses a
ConstCharArrayDetector-based one, which was similarly broken and has been fixed
in b66387574e "Fix -Werror=array-bounds"), so
there's no test for that here.
Change-Id: I7cf10ee5ce0e4280a91d116cd82d4871a0f44af6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> In file included from svtools/source/svrtf/parrtf.cxx:28:
> In member function ‘typename rtl::libreoffice_internal::ConstCharArrayDetector<T, rtl::OUStringBuffer&>::TypeUtf16 rtl::OUStringBuffer::operator=(T&) [with T = const rtl::OUStringChar_]’,
> inlined from ‘virtual int SvRTFParser::GetNextToken_()’ at svtools/source/svrtf/parrtf.cxx:183:94:
> include/rtl/ustrbuf.hxx:352:20: error: array subscript ‘unsigned int[0]’ is partly outside array bounds of ‘rtl::OUStringChar [1]’ {aka ‘const rtl::OUStringChar_ [1]’} [-Werror=array-bounds]
> 352 | std::memcpy(
> | ~~~~~~~~~~~^
> 353 | pData->buffer,
> | ~~~~~~~~~~~~~~
> 354 | libreoffice_internal::ConstCharArrayDetector<T>::toPointer(literal),
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 355 | (n + 1) * sizeof (sal_Unicode)); //TODO: check for overflow
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> svtools/source/svrtf/parrtf.cxx: In member function ‘virtual int SvRTFParser::GetNextToken_()’:
> svtools/source/svrtf/parrtf.cxx:183:94: note: object ‘<anonymous>’ of size 2
> 183 | aToken = OUStringChar( static_cast<sal_Unicode>(nTokenValue) );
> | ^
as seen with recent GCC 12 trunk in an --enable-optimized build.
And add a test, even though it is relatively likely that the OUStringChar
temporary is followed by null bytes, which would make the test happen to
erroneously succeed. But at least tools like ASan or Valgrind could catch that.
(For the corresponding OStringChar and OStringBuffer scenario, this issue does
not arise, as OStringChar is not covered by ConstCharArrayDetector, so the
correpsonding OStringBuffer assignment operator is OK memcpy'ing n+1 elements.
There /are/ similar issues with string_view assignment operators for both
O[U]StringBuffer, which will be addressed in a later commit.)
Change-Id: Ia131d763aa5f8df45b9625f296408cc935df96ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132354
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...once we have a C++20 baseline, which would render uses of the consteval
O[U]StringLiteral ctors ill-formed if we accidentally failed to write to all of
buffer's elements. This had been broken (and the TODO comments had become
misleading) with 21584b304b "make
OUString(OUStringLiteral) constructor constexpr" and
bca539e889 "make OString(OStringLiteral)
constructor constexpr".
Also add corresponding test code.
Change-Id: I2bc680282c717d403a681ff4b9396580c8382de1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132275
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As the OUString equivalent shows, it needs to check == 0. Commit
33ecd0d5c4 for some reason also
dropped the cheap checks (even from OUString) that OString has,
so add them.
Change-Id: I88e68b5ae10fd76c3c08b9b36d5abed0fad17bbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130753
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
Tweak INetURLObject to reduce the number of
OUString and OUStringBuffer we create,
saves 5%
And add a asView() method to OUStringConstExpr,
to make it easier to pass to OUStringBuffer::insert
Change-Id: I115ec2398cfc8df39bd1efbbd5f0d5cc9712dba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125600
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
rtl::math::isValidArcArg's comment talks about 2^64 = 1.844e19; but
the calculation resulted in 2^63.
Unfortunately we can't use C++17 hex-exponent notation in published
API header.
Change-Id: I1dd6e754431ad028982623ff5de4c6329fd6c2ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125348
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...which can be subsumed by their OUString vs. OUString counterparts now that
conversion from OUStringLiteral to OUString is cheap since
e6dfaf9f44 "Turn OUStringLiteral into a
consteval'ed, static-refcound rtl_uString". (The only place that needed
adaption was the dubious use of temporary OUStringLiteral instances in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx, which now caused "error:
conversion function from 'rtlunittest::OUStringLiteral<6>' to
'const rtlunittest::OUString' invokes a deleted function".)
Change-Id: I4f0f96efa2d5331ed5cbc9a29bdfdf3c0f4148a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which are already adequately covered by overloads for OUString and the
OUStringLiteral-to-OUString implicit conversion that became cheap in
e6dfaf9f44 "Turn OUStringLiteral into a
consteval'ed, static-refcound rtl_uString".
The only place where the removal of the ctor overload caused an issue for copy-
initialization (in sfx2/source/appl/newhelp.cxx) could easily be rewritten using
direct-initialization.
Change-Id: I458fb80eebabf981633f3437e7e967caa4c50a5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124176
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by making the OUString's pData point to the OUStringLiteral, instead of
copying the contained characters. This is one of the improvements that had not
been done as part of e6dfaf9f44 "Turn
OUStringLiteral into a consteval'ed, static-refcound rtl_uString": "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." (Simply
dropping the OUStringLiteral overload was not possible in this case, though, as
that would have lead to ambiguities among the various OUString and
std::u16string_view overloads.)
The now-deleted OUStringLiteral rvalue reference overload means that some
existing assignments from ternary-operator OUStringLiteral<N> to OUString no
longer compile and had to be replaced with uses of std::u16string_view. Those
had not already been replaced in e6dfaf9f44
because they happened to use OUStringLiteral instances of identical length N in
both arms of the ternary operator, so did not already start to fail to compile
back then.
Change-Id: I328e25b8324d045774e811d20a639f40d6a9a960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124040
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For the
rtl_str_to<NumberType>_WithLength
category of functions, the string does not need to be null-terminated
Change-Id: I1971c8c10b760743633523e6f680366eafdfc685
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119325
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...like it is also already done in LineParser::readDouble in
sdext/source/pdfimport/wrapper/wrapper.cxx (esp. since the code should be
changed to use C++17 std::from_chars once that is available in all our
baselines), reverting again the introduction of rtl_str_toDouble_WithLength in
b1df9c6734 "[API CHANGE] reduce cost of numeric
conversion"
Change-Id: If7e3a15649f80093d3407157412fd3deb3a38b12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
Mike Kaganski