...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>
df42cb6552