add the macOS specific suffixes from
https: //support.google.com/mail/answer/6590?hl=en#zippy=%2Cmessages-that-have-attachments
Change-Id: I3a834694e3aefb757974cd00ade009874c68c8b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130397
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I quickly gave up trying to understand what exactly clashes
between the Emscripten macros and OUString templates /
initializers. Not sure it can actually be "fixed".
Also disables the makeshared clang compilerplugin; currently
there is no way to get rid of all the false positive hits
when assigning the std::shared_ptr from a function instead of
a constructor call.
Change-Id: I8b13f179629ea63ff221584030556d2bedadc01b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128604
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This allows to avoid use of module name when obtaining current module
handle, which needs to be synchronized and thus is error-prone.
Change-Id: I2f0e0af7f616c3582b0a3271cf9e06420a9dfc8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127993
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
This caused CppunitTest_sw_dialogs_test to fail for LO_TEST_LOCALE=or hitting
> sal/rtl/ustring.cxx:530: void rtl_uString_newFromAscii(rtl_uString**, const char*): Assertion `static_cast<unsigned char>(*pCharStr) < 0x80' failed.
at
> #4 0x00007fd18a844f74 in rtl_uString_newFromAscii(rtl_uString**, char const*) (ppThis=0x7ffcb73e6e90, pCharStr=0x6191180 "ସମୟ ସୀମା ପହଞ୍ଚିଯାଇଛି") at sal/rtl/ustring.cxx:530
> #5 0x00007fd1525af9c1 in rtl::OUString::createFromAscii(char const*) (value=0x6191180 "ସମୟ ସୀମା ପହଞ୍ଚିଯାଇଛି") at include/rtl/ustring.hxx:3328
> #6 0x00007fd1525ad026 in (anonymous namespace)::GErrorWrapper::~GErrorWrapper() (this=0x7ffcb73e6f38, __in_chrg=<optimized out>) at shell/source/sessioninstall/SyncDbusSessionHelper.cxx:35
> #7 0x00007fd1525ad6a5 in (anonymous namespace)::request(char const*, com::sun::star::uno::Sequence<rtl::OUString> const&, std::u16string_view) (method=0x7fd1525b481d "InstallFontconfigResources", resources=uno::Sequence of length 1 = {...}, interaction=u"hide-finished") at shell/source/sessioninstall/SyncDbusSessionHelper.cxx:91
> #8 0x00007fd1525ada9d in shell::sessioninstall::SyncDbusSessionHelper::InstallFontconfigResources(com::sun::star::uno::Sequence<rtl::OUString> const&, rtl::OUString const&) (this=0x5d22380, resources=uno::Sequence of length 1 = {...}, interaction="hide-finished") at shell/source/sessioninstall/SyncDbusSessionHelper.cxx:158
> #9 0x00007fd178670daa in psp::PrintFontManager::autoInstallFontLangSupport(Timer*) (this=0x2e3ed90) at vcl/unx/generic/fontmanager/fontconfig.cxx:962
> #10 0x00007fd178670cd9 in psp::PrintFontManager::LinkStubautoInstallFontLangSupport(void*, Timer*) (instance=0x2e3ed90, data=0x2e3efa0) at vcl/unx/generic/fontmanager/fontconfig.cxx:956
> #11 0x00007fd178341e03 in Link<Timer*, void>::Call(Timer*) const (this=0x2e3efc0, data=0x2e3efa0) at include/tools/link.hxx:111
[...]
(But probably better to use the lenient OUString-from-rtl_TextEncoding ctor
rather than OUString::fromUtf8, in case GError::message happens to not contain
proper UTF-8 after all, which would make the latter assert.)
Change-Id: I61fede4576988c5f7f35bb071ab3f2c0e7a15aa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122599
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...revealing that these places apparently wanted to assign to *pClassID rather
than pClassID ever since their introduction with
b718f390bf "INTEGRATION: CWS desktintgr01" and
9b1b1b0081 "INTEGRATION: CWS desktintgr02"
Change-Id: I672684739fd2722c5e804f47790884174c576369
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117840
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to "..."+OUStringToOString(...), in preparation of making OUStringToOString
take a std::u16string_view
Change-Id: Ic01ca249d4d0eb58ac959ffdf96471308a3715dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107600
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>
...assuming the way of constructing an OUString from just a QString::utf16
pointer, ignoring QString::size, was not chosen deliberately to cut of the input
string at a potential embedded NUL.
(This change is a prerequisite for making the OUString ctor taking a raw pointer
explicit.)
Change-Id: I3fb3026065f0247c19f0497d28adf422106bd9c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102083
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>
Stephan Bergmann