...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>
used
git grep -lw namespace
| xargs perl -i -p0e 's/(\w+)\s*.\{.\s*namespace\s*(\w+)/\1::\2/smg;'
to do the initial replace, then compiled and fixed.
Change-Id: If69904d75940c851aeffab0e78c4ba02cc968d44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
.. and a few cases of instead doing blacklist->excludelist where that
made more sense.
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist
[API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice
[API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList
Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Except for MAC/WIN specific parts (i.e. most of it)
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ia14fb27c047e0e69f81386212aa25344f1297e05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95663
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
RT_RCDATA is defined as MAKEINTRESOURCE(10) in WinUser.h, and MAKEINTRESOURCE is
defined as MAKEINTRESOURCEA in WinUser.h absent a definition of UNICODE.
649854544e "WinAPI: Fix some leftovers having
UNICODE-define-dependency" had changed this
> - HRSRC hrc = FindResourceW(g_hModule, L"#2000", RT_RCDATA);
> + HRSRC hrc = FindResourceW(g_hModule, L"#2000", MAKEINTRESOURCEW(RT_RCDATA));
before 558956dc81 "Drop UNICODE/_UNICODE defines"
dropped defining UNICODE. But that change was technically wrong, as now flagged
by LLVM 10 trunk clang-cl:
> C:/lo-clang/core/shell/source/win32/shlxthandler/thumbviewer/thumbviewer.cxx(50,56): error: cast to smaller integer type 'unsigned short' from 'char *' [-Werror,-Wpointer-to-int-cast]
> HRSRC hrc = FindResourceW(g_hModule, L"#2000", MAKEINTRESOURCEW(RT_RCDATA));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> C:/PROGRA~2/WI3CF2~1/10/Include/10.0.18362.0/um\winuser.h(236,51): note: expanded from macro 'MAKEINTRESOURCEW'
> #define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
> ^~~~~~~~~
There appears to be no explicit define for MAKEINTRESOURCEW(10), and the fix
presented here seems like a cleaner way than replacing the use of RC_RCDATA with
MAKEINTRESOURCEW(10).
Change-Id: I36f60a8647ac264085656fc9ec3b129c2d81f480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90799
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
Unify Windows header usage (wrap into prewin/postwin, remove redundant);
replace "using" with explicit namespace usage; drop some indirection.
Change-Id: Ia635e732de7165b161935c05d54d0490464248b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87571
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Mike Kaganski