| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Common::Misc::OpenCLWhiteList -> OpenCLAllowList
Change-Id: I65636b19b13e4af1e4851f70e78053f3443d6bb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98181
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...to find StringLiteral on the RHS of +=. Which revealed that the
VisitCompoundStmt/checkForCompoundAssign logic needed to be fixed, too, so that
s += side_effect();
s += "literal";
s += side_effect();
only gets combined to
s += side_effect() + "literal";
s += side_effect();
and not all the way to
s += side_effect() + "literal" + side_effect();
Change-Id: I432e3458b933a7d0ad6141c747b675cc8b0f0ba4
Reviewed-on: https://gerrit.libreoffice.org/81804
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
...since 6d6fad522a2cd6a2959ea774969a86288f5a3cb7 "Introduce OStringChar" (and
had needlessly been kept alive with ce3badb157c58941608f878a7de98c7739e30aec
"compilerplugins: fix -Werror,-Wunused-lambda-capture")
Change-Id: Ie34ef1197f97ecab5b8f30741f1e2c4b3a9db594
Reviewed-on: https://gerrit.libreoffice.org/81591
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
if one side of the expression is a compile-time-constant, we don't need
to worry about side-effects on the other side
Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b
Reviewed-on: https://gerrit.libreoffice.org/81589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
| |
|
|
| |
Change-Id: I2a1374a1e79401c2107d003102ab797fac9a3d66
|
| |
|
|
|
|
|
|
|
|
| |
...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>
|
| |
|
|
|
|
|
|
|
| |
it caused clang-cl to crash when processing desktop/source/app/opencl.cxx
Change-Id: I0a39697e75242cd00f12b60477d51a1e5bf96a4f
Reviewed-on: https://gerrit.libreoffice.org/81409
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
| |
|
|
|
|
|
| |
Change-Id: I7752c281b1b6dd0d26bd7d6c4a6896c663f4cbc3
Reviewed-on: https://gerrit.libreoffice.org/80921
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
| |
|
|
|
|
|
| |
Change-Id: Ifbdb3e41eae665f7dcaf5301aaba2b6e4662cf48
Reviewed-on: https://gerrit.libreoffice.org/80855
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
| |
|
|
|
|
|
| |
Change-Id: I8b87c4e56f10417acd538b765b3f8e4cc6e12fb9
Reviewed-on: https://gerrit.libreoffice.org/80844
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...after 9b5dad13b56bdde7c40970351af3da3a2c3c9350 "loplugin:stringadd look for
unnecessary temporaries". There was no reason to check for implicit
MaterializeTemporaryExpr instead of explicitly written CXXFunctionalCastExpr,
and checking for the latter makes it easier to report the casted-from type,
which gives useful information how to change code that exhibits the warning.
See the comments at <https://gerrit.libreoffice.org/#/c/80724/>
"loplugin:stringadd look for unnecessary temporaries" for details.
(And while at it, remove some commented-out debug code that is probably no
longer relevant now.)
Change-Id: I7d4cab85432885d617dd7114c75163c1eb376fc2
Reviewed-on: https://gerrit.libreoffice.org/80823
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
| |
|
|
|
|
| |
(The use of it is also commented out.)
Change-Id: Ie015a8cbd0f7a982721a389487c2134a1aba8ed1
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
look for places where we can replace sequential additions to
OUString/OString with one concatentation (i.e. +) expression, which is
more efficient
Change-Id: I64d91328bf64828d8328b1cad9e90953c0a75663
Reviewed-on: https://gerrit.libreoffice.org/79406
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
