Each call to css::i18n::XTextSearch::SearchForward transliterates input string,
making performance of repeated calls unacceptable. So prepare the transliterated
strings once, and use the offset sequence to map search results to indices into
original string.
Change-Id: Ie08dd5a408aca9a950067db285a480b41a3f9a16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129162
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In addtion, fixed a crash if the start position is greater than the
length of the string being searched.
Change-Id: I9bcda1131324bdfac6957018e91b3a36dd2dc3d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118996
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
In the old algorithm, some special unicode characters lead to a
malfunction of basic's replace function. For instance, replacing a
German ß to uppercase in the insensitive case will lead to SS, breaking
the replace positions.
Change-Id: I4e6f6e5fba3d560b8cfd0786fa2439ed5174a928
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118760
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
* vbUnicode/vbFromUnicode considers optional third LCID argument.
* LCID is also used for other conversions.
* The encoding is decided based on the language defined in LCID,
or on program locale when LCID is omitted, using MS default
ACP mapping for languages.
* Unit testis for vbWide / vbNarrow are changed and enabled.
* Unit tests for vbKatakana / vbHiragana are changed and enabled.
* Unit test for vbFromUnicode / vbUnicode is changed to rely on
en-US locale used in testing, and is enabled.
Change-Id: Iabd4153db311cd02c3f3e7247f9fc71ad9f5f682
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112539
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
ReadImpGraphic and WriteImpGraphic have been reimplemented in the
TypeSerializer some time ago, but the code has not yet been moved
to use that class. This commits does that and changes all the code
using those 2 methods and removes them. With this implemented in
the TypeSerializer, it is easier to handle
In addition it also removes ImplExportNative (and the method on
the Graphic interface). This was really used only in one method,
and it could be implemented in the mthod itself.
Change-Id: I0982429d1c1d5ed7ef07627d87ed9a08df43f040
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108256
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.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>
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...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>
Using option base, every array should start at index 1. Previously, it
needed option VBASupport too. Without option compatible, the upper bound
of an array is increased as well in order to preserve the specified
size.
Change-Id: I52885f14914a4636b98258aa428c2123f62482a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101269
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...that are helpfully deleted in C++20, as now implemented at least by VS 2019
16.6.4 when using --with-latest-c++
Change-Id: Iaf80f793e73fc90768bb146c9cf3d300d6747c8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99170
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It should not convert strings to uppercase each loop; it should use
OUStringBuffer to avoid extra allocations.
This reduces tick count for the code in the bug from ~6000 to ~30.
Change-Id: I89ea062fc6d012464bb461b6a8ef321f8cc62fe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92884
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The documentation of _getdcwd/_wgetdcwd specifies: "If the specified drive
isn't available, or the kind of drive (for example, removable, fixed, CD-ROM,
RAM disk, or network drive) can't be determined, the invalid-parameter handler
is invoked." (<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/
getdcwd-wgetdcwd?view=vs-2017>) The default handler terminates the process, so
temporarily install a "harmless" one.
(e30f3bcd25 "Revert 'fdo#38913: Prevent invalid
parameter handler crashes'" had removed a global "harmless" handler installed
with _set_invalid_parameter_handler to handle JVM-related issues, but which was
then considered no longer necessary. I assume that for those JVM-related issues
there was no obvious place where to install a temporary
_set_thread_local_invalid_parameter_handler, and that that was the reason for
the global _set_invalid_parameter_handler in sal_detail_initialize. I cannot
find any information that _set_thread_local_invalid_parameter_handler would be
available in fewer versions of Windows than _set_invalid_parameter_handler, and
might even be missing on Windows versions that we target.)
(It appears that at least when building with MSVC 2019 and running on Windows 8,
with an --enable-dbgutil build (presumably due to MSVC_USE_DEBUG_RUNTIME) a
"Microsoft Visual C++ Runtime Library: Debug Assertion Failed!" error dialog
still pops up, which needs to be quit with "Ignore" before our
invalidParameterHandler is called.)
Change-Id: I983d622eb03549873a63305f51bf0869d7fea33a
Reviewed-on: https://gerrit.libreoffice.org/84597
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I325149be2ea7697b5b4a2ce4a662edd2f8be6e50
Reviewed-on: https://gerrit.libreoffice.org/82312
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
offtkp