SbxVariable::NameToCaseInsensitiveName might then be used wherever
such names may be needed (see e.g. tdf#148358).
Change-Id: I7749a12a05225398848cbf72700c6f0bc119bc22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132561
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Simply include the global transliterator in all builds.
Regression from commit de81c2545a
("Related: tdf#144245 Optimize case-insensitive handling").
Change-Id: Ica1c6e5d67c8458f9977f2ff87d9594a43b4cff2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132517
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
1. Make BasicCollection::implGetIndexForName take OUString again,
after commit f7de7de118 made it take
std::u16string_view. All call sites pass OUStrings, and commit
ef32c3b4f9 made it create OUString
from the argument.
2. Have SbxVariable cache a case-insensitive variant of the name.
It is currently only used in the Collection implementation, but
may be used in other places; Tthe names are case-insensitive in
Basic, and VBA allows non-ASCII characters in names, so this
caching might be useful elsewhere.
3. Skip non-ASCII characters when calculating name hash, to allow
non-ASCII-containing strings still have some hash variance, when
at least some of the first 6 characters are ASCII.
Change-Id: If90ccea2c4b44c34967e6b764b6fab45b2976c40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132493
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...like my local ASan+UBSan build, which now happened to fail once with
> Failed: TestReplacePerformance (t = 60 s)
> Tests passed: 0
> Tests failed: 1
when the machine was under load during a parallelizing `make check`, following
up on 3564b5c6e9 "Adapt test to slow builds"
Change-Id: I8f0c8f7e6e145b6d5009f48d2af865ea5caab375
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
BSTR is documented [1] to be prefixed by a 32-bit integer specifying
its length *in bytes* (not characters), so passing wchar_t* as BSTR
is wrong, and the length member of rtl_uString can't substitute the
proper BSTR length, since rtl_uString::length specifies length in
characters. Any code taking BSTR and using SysStringLen to get its
length would only get half of the passed OUString data.
In dbaccess/source/ui/dlg/adodatalinks.cxx, the abovementioned
error was implemented. OTOH, OLEVariant::getByteSequence() in
connectivity/source/drivers/ado/Aolevariant.cxx passed BSTR from
tagVARIANT to ctor of OLEString, which resulted in the BSTR being
freed in both dtors of OLEString and OLEVariant (the latter calls
VariantClear, which itself clears string when vtfield is VT_BSTR).
[1] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/automat/bstr
Change-Id: Iedbd62b20133644258af3660616add7b63cac258
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131950
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
First, the integer function result is returned in a 64-bit register (RAX),
and truncation it to sal_Int32 breaks any pointer return value.
Second, using explicit (not vararg) first function double argument would
pass it through XMM0, without also copying it to RCX (which is guaranteed
for varargs).
Ref: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention
Change-Id: I08212c44d8690d6910068b13c16af2ce899c94f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129808
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...like my local ASan+UBSan build, which kept failing with
> Failed: TestReplacePerformance (t = 35 s)
> Tests passed: 0
> Tests failed: 1
when the machine was under load during a parallelizing `make check`
Change-Id: I59c81a61a29df7165f6fad33e3fe3da975f05ed2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129237
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I hope that this performance test is OK. I chose 20 s threshold, as
it works much faster on my system (under 4 s); it shouldn't be much
slower elsewhere; and both the original bug, and the regression that
followed the initial fix, made it execute orders of magnitute slower
(I expect hours on fast systems).
Change-Id: I75ee4c60e562473fe70a203faa94b48c5fbfb4fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
(*) make all the methods that require an external mutex take a
std::unique_lock as a parameter, so that call sites cannot forget
(*) make the forEach method drop the lock when firing listener methods,
to reduce the odds of deadlock
Change-Id: I0a80e3b3d1c1c03b7de4a658d31fcc2847690903
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128415
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
During the assignment of a variable, copy its information only if there
isn't already one present.
Change-Id: I29fcfcd10406f2af0708a879d57e0a3c704f179e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127387
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
This was an implementation error ever since it was introduced
in commit 79d3bc4799.
The function is used to release the refcounted object, and the
calling code does not always set the pointer to another value
or discard it (see uses in basic/source/sbx/sbxvalue.cxx). If
it resets the pointer in some cases, it must do it always.
Change-Id: I17de412914935082d20f2a1a91ea6e4e289936aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127254
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>