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>
Stephan Bergmann