...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>
* In the URIS_ONLY case (which is intended to open documents etc.), set
preprocessed_command to the filesystem pathname the first time that is
computed (and which will no longer fail for file URLs with fragment since
14b36a16b2 "Remove a fragment from a file URL
early on").
* In the !URIS_ONLY case (which is intended to run other programs), we will
generally be called with aCommand already being a filesystem pathname. But
even if it should be a file URL, it appears to be OK to pass that as-is to
ShellExecuteExW: At least on Windows 8, passing
"file:///C:/Windows/System32/notepad.exe" does start it.
* The code for <https://bz.apache.org/ooo/show_bug.cgi?id=4789> "Hyperlinks
doesnt works" should no longer be relevant: In the URIS_ONLY case, any
fragment (called a "jump mark" in that code) has already been removed from the
incoming URL now. In the !URIS_ONLY case, we should generally not be called
with a URL with a fragment, but even if we are, it should be OK to pass that
as-is to ShellExecuteExW and let it handle that (see above).
* Similarly, the code for
<https://bugs.documentfoundation.org/show_bug.cgi?id=54204> "Hyperlinks
between documents not works if link contains anchor at the end" is no longer
relevant for the same reason.
Change-Id: Ia6ec80a30f6d0603bccc87b9d6dd93ca6a84c370
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86975
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
PROPERTYMAP members pszXPathParent and pszValueNodeName were unused ever since
85e0cc246d "dv17: #i70994#: Use property handler
instead of column info for Windows Vista" introduced the code. (And removing
them allowed to simplify the code further in the obvious way.)
Change-Id: Ie1247cbee31a172a15fd57c4b752d74711b1d3a1
Reviewed-on: https://gerrit.libreoffice.org/84860
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* OldEntry in fpicker/source/aqua/resourceprovider.mm was apparently unused ever
since it got introduced with 00657aef09
"migrate to boost::gettext"
* impl_throwError is used from multiple TU,
connectivity/source/drivers/macab/MacabStatement.cxx just missed the relevant
#include
Change-Id: Iba131da57aa20085bb1c634ba9a3a59566070abd
Reviewed-on: https://gerrit.libreoffice.org/84653
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Where option "-R" means, according to the open(1) man page: "Reveals the file(s)
in the Finder instead of opening them." This appears to always reveal in
Finder, even for *.app "application directories", so should not affect
CVE-2019-9847.)
Change-Id: I775db7bf71c09adc6570931a977b82dfee8dc95a
Reviewed-on: https://gerrit.libreoffice.org/82749
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Non-ASCII file links didn't work when the link contains anchor at
the end.
Note: The "correct" way to convert from a LO-internal to -external
file URL would be the translateToExternal method of the
css.uri.ExternalUriReferenceTranslator UNO service. But that
translates the URL to be interpreted according to the current Windows
code page (i.e., osl_getThreadTextEncoding), so only supports
characters covered by that code page, and given that the result is
passed into a Windows wchar_t API, ToIUri nicely avoids such potential
conversion failure.
Change-Id: I1a5b07366b0fea3da2fbe11a9378aacd765b5e04
Reviewed-on: https://gerrit.libreoffice.org/82219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Philipp Hofer