Age | Commit message (Collapse) | Author |
|
The function expects elements starting from smallest to the biggest,
and finds the first one that is not smaller than the one searched for.
That means that all items remaining will not be smaller, and thus
end of search is when items compare larger. Comparing remaining
items as smaller means searching until the end.
Change-Id: If5cf5c18951abf987ddbbf201f49cfb195e36d32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130220
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
speeds up loading a large chart by 5%
Change-Id: Idd8566012a0049d429e38b589782fc6d76eb3a5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130132
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to prevent object slicing.
Which reveals a problems with
commit 044fa30a4c77013c87a7e2a6dd9022a2f6599778
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Sep 23 18:44:42 2021 +0200
no need to allocate this SfxItemSet on the heap
and
commit 044fa30a4c77013c87a7e2a6dd9022a2f6599778
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Sep 23 18:44:42 2021 +0200
no need to allocate this SfxItemSet on the heap
so revert the problematic bits of those commits
Change-Id: I5eeba1d5bdb91f4e539850516f2b1c11e69ff2c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130127
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(Somewhat oddly, there is no OStringBuffer::copy counterpart.)
This required some modification to StringView::VisitCXXConstructExpr to avoid
> In file included from odk/qa/checkapi/checkapi.cxx:29:
> In file included from workdir/CustomTarget/odk/allheaders/allheaders.hxx:351:
> In file included from instdir/sdk/include/rtl/math.hxx:31:
> instdir/sdk/include/rtl/ustrbuf.hxx:1687:16: error: rather than copy, pass with a view using subView() [loplugin:stringview]
> return copy( beginIndex, getLength() - beginIndex );
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
while building CppunitTest_odk_checkapi as external C++03 code, where the
returned value is wrapped in a CXXConstructExpr. And testing for that case
required a new CompilerTest_compilerplugins_clang-c++03 that uses gb_CXX03FLAGS
and needs to not set LIBO_INTERNAL_ONLY (via gb_CompilerTest_set_external_code),
as compiling as C++03 would otherwise generate lots of errors like unknown
char16_t at include/sal/types.h:118. (There was a choice whether to name the
new test "-c++03" or "-external", but the issue it tests is caused more by the
code being compiled with C++03 than by this being external code, see above.)
Change-Id: I873a9c5a70d3ea949cf13a169d46920b71282712
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130036
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As pointed out by 585e0ac43b9bd8a2f714903034e435c84ae3fc96, some
item types cannot be used as IsSortable(), because they are modified
after having been inserted in the pool, which breaks the sorted
order. But it's possible to at least somewhat improve performance
of these items by explicitly providing a hash code and using
that first for comparisons when looking up items, which may be
cheaper than calling operator==.
With ScPatternAttr such comparisons seem to take only 60% of the
original time, reducing loading time of some documents by 25%.
Change-Id: I41f4dda472fb6db066742976672f2c08b9aeef63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129667
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
REPLACE is really a replaceAndFind instead of a findAndReplace.
Thus, when you changed your search parameter and did a replace,
it replaced the previously searched for item, and then found the
first instance of the new search parameter.
That of course is just wrong.
So make sure to verify that the previous search
matches the current search competely.
However, that doesn't mean that the entire searchItem matches,
since we don't want to restart the search just
because the replace parameter changed.
In my testing, this wasn't an issue for REPLACE_ALL.
So the only time we need to worry about the last search
result is in a replace once situation.
P.S. This commit exposed that mpSearchItem can point
to a destructed SvxSearchItem, so this patches unit test
will crash if the other 7.4 commit is missing.
Change-Id: I7be14d64534018718145c6ac5f8629ff5f2e5611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129385
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id9e18e66f3b3c583d7cb22ee0a5d6272ca2f7ea9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129556
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I6f1df008e2b51ff42d058f2c4f37393066798c93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129555
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and once we remove that self mapping, no need to call GetWhich for those
IDs either
Change-Id: Ia881328a29bb022dace8d5f25c57279a381e0377
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since it extends SfxInt32Item
been this way since
commit 5f51e579fc2e3207166b053382ca14b95082728c
Date: Wed Apr 11 18:28:13 2007 +0000
INTEGRATION: CWS hedaburemove01 (1.1.2); FILE ADDED
2007/02/09 16:12:44 vg 1.1.2.1: #72503# get rid of hedabu procedure:
Moving headers to svtools/inc/svtools and correspondent necessary
changes
Change-Id: Id23909c5cb842b858baf2f6918298607a79adcec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129402
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
only instantiated with one type, so just turn it into a normal class
Change-Id: If3ae908f3e226ae9f4d3b81a7a7d9ba492ccda4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129283
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
where nCurrentPosition was wrapping around
Change-Id: I839215f3138d58884f03509b6341147ef28edb4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129108
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
regression from
commit 62efb188668a3296591dcfa3658185e2f982e356
use comphelper::WeakComponentImplHelper in SlideShowVie
Switch notifyEach to leave the mutex locked after being called,
because that seems to compose better - because after a call
it is in the same state that was when we entered the call.
Change-Id: I42e80cc7be1b65ed8cab24ab7c11210e056d916d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128723
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(*) 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>
|
|
... and avoid OUStringBuffer::toString when the temporary is used
for checking current buffer content
Change-Id: I114178f3e74ca3e4a3e517763f9eaab4797b7deb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127478
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I99abbe97a48b2077e28d6221fb70036e5e412657
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127479
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I66feced8bed05c7859e36a6d2f746a7faf30c7a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126915
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
The task presents an URL that ends with a closing bracket. If
pasted to LO, the closing bracket got interpreted as not being part
of the URL due to the heuristical interpretation of URLs in
urihelper.
Adapted this to handle matching brackets, so that an closing and
ending bracket will be added to the uri text when there is a
matching pair.
Added unit test to testFindFirstURLInText with simplified uri
example.
Change-Id: I58dd460a37d0066ff46845832eabd2a790e4ccd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126832
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It's somewhat confusing that an accessor is provided to give
a reference to internal data and then the object is modified
indirectly using the reference. It appears to be only for
performance reasons, so I thought that inlining the ctor and
ctor could help the compiler to optimize this, but apparently
it can't move this outside of the loop, so at least make it
clearer.
Change-Id: I72cf15d1446daa559ac4079b9478e53694d7d198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126394
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I93443f87fe9b68157cc9a126f2c31f917a016a1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125975
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
They are tiny and they are used in performance-critical parts
of Calc.
Change-Id: If227b11ac7929dd1369545a590d8ef1a977185f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125698
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
avoid a copy in INetURLHistory::QueryUrl, saves 10%
Change-Id: I662a4e48f198e61f1cef52b1e920613bce9c9766
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125563
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I49a8062c30bdce5b0d9bd27e421d85ba61d5592e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125544
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(regression from 7256ff08bc46840bb85fa255ace6541dca91329e)
Change-Id: Ib640dea001fc787279761ca72bbc3db46d0102c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125485
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: Idadc4dc77eb681a8b8923ffacf37ddbe1d8245e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125425
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Instead of manually moving out, moving a range and then moving in.
Change-Id: Iaff461e1fcee3936c8ddc02bf471a804e7881aef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125219
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Previously we assumed that the action to be executed is always exactly
the top of the undo stack minus 1 element.
Extend this, so that in case an other view appends two or more elements
to the undo stack, we still find our undo action. Obviously only do this
if all those undo actions are independent from us.
This requires replacing the swap in svl/ with a move-out + move a range
down + move in construct.
Change-Id: Ic12d32d6eb5e77618d99eddb4fa096802f32d655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125076
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Specifically, we used to not allow out of order undo at all if the redo
list was non-empty. This relaxes that condition a bit. Out of order undo
is OK with a non-empty redo list, in case all undo actions in the redo
list are either
1) owned by the current view or
2) independent from the undo action to be executed
I.e. if view1 has lots of type undo actions and an view2 adds a
single type undo action on top of it, then allow view 1 to execute
multiple of its typing undo actions, not just a single one.
Change-Id: I2f5d9404a9994ed74b65233d2a315976c27b28b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125023
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Undoing out of order is dangerous by default, so limit this to a very
specific case as a start, that allows growing in follow-up commits.
For now, allow out of order undo if:
1) redo stack is empty
2) we're in LOK mode (different views represent different users)
3) we undo a single action (count is 1)
4) the top undo action doesn't belong to the current view
5) the top and the previous undo actions are independent
Which only requires that SwUndoInsert::UndoImpl() is independent for two
different paragraphs, which seems to be the case.
Independent undo actions opt in for this, currently the only such
allowed undo action is SwUndoInsert ("typing"), which adds characters to
a single text node. Even those are only considered independent if they
operate on different text nodes.
On the positive side, this allows out of order undo in the frequent case
where two users collaborate on a long document and they just type some
new content into the document at different paragraphs.
Change-Id: Ibb4551e8f7046b4947491b8bf751eaa0cbb2d060
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124949
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
There's no, specifically not in Writer, handling of the LCID
0x0400 LANGUAGE_PROCESS_OR_USER_DEFAULT language/locale concept
other than the number formatter mapping it to LANGUAGE_SYSTEM.
Use the LANGUAGE_SYSTEM "Default" string in UI (status bar, status
menu, language list) but keep the LCID, and don't append the
resolved locale string as it is also displayed both in the Font
Western and CJK listboxes.
This ends up as two list entries, like
* Default - English (UK) first entry
* Default last entry
of which the second would be selected.
Change-Id: I8d9e4171bee6bbe9d1c9dcfb7a5fa8fc92ea1a2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124449
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I6b71a075de5d5ac002dc48cd2bb21ff5bf5dd072
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124395
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...which defines NULL as a plain 0 integer literal instead of the GNU __null
extension, so clang-cl's -Wnull-conversion cannot kick in. These findings are
from an experimental build done with clang-cl and a modified
> --- a/clang/lib/Headers/stddef.h
> +++ b/clang/lib/Headers/stddef.h
> @@ -83,6 +83,10 @@ typedef __WCHAR_TYPE__ wchar_t;
> # if !defined(__MINGW32__) && !defined(_MSC_VER)
> # define NULL __null
> # else
> -# define NULL 0
> +# if __cplusplus >= 201103L
> +# define NULL nullptr
> +# else
> +# define NULL 0
> +# endif
> # endif
> #else
> # define NULL ((void*)0)
However, that build also ran into lots of places where 3rd-party code in
external/ and Windows system headers caused issues when NULL is nullptr (which
I worked around with various hacky patches for that build), so this is
unfortunately not something that can easily be enabled generally.
Change-Id: I10674464498a9bc63578d9e6cc32ddde23ab4f30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124419
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Applying a numbering style to text causes export to save that
out as a number (valued as zero). That is not good because
the ODF spec says that a number overrides a string.
So don't accept a numbering format on non-number text.
Why is this change good?
-the cell previously had no direct formatting (by definition).
-the cell's previous old format was text (tested).
-any numbering format applied obviously isn't correct (by definition).
-any previous formatting has already been overwritten with numformat.
-the default numbering is appropriate for text.
-empty cells still get the numbering format (tested).
-odd human-designed formats are accepted as intentional (tested).
What are the concerns?
-the scope of this change is HUGE, way beyond this bug.
-on both my dev box and patch box I saw occassional crashes.
-the bug was "fixed" by a different import commit that ensured
different languages were treated consistently.
So this patch is no longer critical, just nice to have
to avoid exporting out-of-spec content.
Change-Id: Id3dc5f803c3cf4875bc0cab52d1019a18679da77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123904
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Semantics were temporarily changed with
commit bba6a4ed92a0feb288a9dedd648d623bee02a3ce
CommitDate: Mon Oct 25 11:18:31 2021 +0200
Get rid of fuzziness in MsLangId::Conversion::convertIsoNamesToLanguage()
Change-Id: I8bbf77998bea81c5691ba518c7ae25093b0df421
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124141
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
With on-the-fly LanguageTag the fuzzy fallbacks for a few
languages aren't needed anymore. Proper fallbacks should be
obtained when needed, like when configuring default locales, or
configured values used after.
Change-Id: I8b85b8099e085508435036ac846db6c3e516dc23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124127
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
...during CppunitTest_svl_qa_cppunit, after
df42cb6552b20372f62b5a361709670db80e4ed4 "Optimize assignment from
OUStringLiteral to OUString",
> ==918==ERROR: AddressSanitizer: stack-use-after-scope on address 0x2b2e203b5900 at pc 0x2b2e1b9004f8 bp 0x7ffc06726270 sp 0x7ffc06726268
> READ of size 4 at 0x2b2e203b5900 thread T0
> #0 0x2b2e1b9004f7 in void rtl::str::release<_rtl_uString>(_rtl_uString*) /sal/rtl/strtmpl.hxx:1064:9
> #1 0x2b2e1b8d916c in rtl_uString_release /sal/rtl/ustring.cxx:1785:12
> #2 0x2b2e36263ec5 in rtl::OUString::~OUString() /include/rtl/ustring.hxx:493:9
> #3 0x2b2e3622c5ff in (anonymous namespace)::Test::testTdf103060() /svl/qa/unit/svl.cxx:553:1
[...]
> [2304, 2320) 'EXPECTED_G3' (line 550) <== Memory access at offset 2304 is inside this variable
(<https://ci.libreoffice.org/job/lo_ubsan/2176/>).
(aa2064c5c5f23f6f4b7bc44e12345b37f66995bc "Improve loplugin:stringliteralvar"
had failed to introduce those OUStringLiteral variables as static.)
Change-Id: I59168979fcc4b055d17d1d4f315577eef1027505
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124134
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8ff1eb008f3173791c7c1020db08d29451998f42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123699
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
... to avoid hidden cost of multiple COW checks, because they
call getArray() internally.
This obsoletes [loplugin:sequenceloop].
Also rename toNonConstRange to asNonConstRange, to reflect that
the result is a view of the sequence, not an independent object.
TODO: also drop non-const operator[], but introduce operator[]
in SequenceRange.
Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit 503ab1ca9ae11978d9717557546c01ff598aaf88, plus follow-up
17915ab5202a4d7456e9bc031c3f6a72bc861844 "fix ubsan alloc-dealloc-mismatch".
It failed to properly destroy the object assembly, and caused e.g.
CppunitTest_svl_items to fail with
> ==850754==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x6060000024e0 in thread T0:
> object passed to delete has wrong type:
> size of the allocated type: 64 bytes;
> size of the deallocated type: 56 bytes.
> #0 in operator delete(void*, unsigned long) at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:164:3 (workdir/LinkTarget/Executable/cppunittester +0x330ae2)
> #1 in SfxItemSet::~SfxItemSet() at svl/source/items/itemset.cxx:202:1 (instdir/program/libsvllo.so +0x110ccf6)
> #2 in std::default_delete<SfxItemSet>::operator()(SfxItemSet*) const at /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/unique_ptr.h:85:2 (instdir/program/libsvllo.so +0x1142a28)
> #3 in std::_Sp_counted_deleter<SfxItemSet*, std::default_delete<SfxItemSet>, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() at /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/shared_ptr_base.h:442:9 (instdir/program/libsvllo.so +0x12696e4)
> #4 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() at /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/shared_ptr_base.h:168:6 (instdir/program/libsvllo.so +0xe500b5)
[...]
> 0x6060000024e0 is located 0 bytes inside of 64-byte region [0x6060000024e0,0x606000002520)
> allocated by thread T0 here:
> #0 in operator new(unsigned long) at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:95:3 (workdir/LinkTarget/Executable/cppunittester +0x32fe7d)
> #1 in SfxItemSet::Clone(bool, SfxItemPool*) const at svl/source/items/itemset.cxx:1270:34 (instdir/program/libsvllo.so +0x1127854)
> #2 in (anonymous namespace)::Node::setItemSet(SfxItemSet const&) at svl/source/items/stylepool.cxx:65:107 (instdir/program/libsvllo.so +0x1212179)
> #3 in StylePoolImpl::insertItemSet(SfxItemSet const&, rtl::OUString const*) at svl/source/items/stylepool.cxx:417:19 (instdir/program/libsvllo.so +0x12103e1)
> #4 in StylePool::insertItemSet(SfxItemSet const&, rtl::OUString const*) at svl/source/items/stylepool.cxx:456:17 (instdir/program/libsvllo.so +0x1212ffb)
[...]
in Clang ASan builds done with -fsized-deallocation.
Change-Id: I3ccba7e7d9712ecabf38a0149252d3cd70cdb446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123446
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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 1250aecd71fabde4dba990bfceb61bbe8e06b8ea
"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>
|
|
Change-Id: Icd45c7f693c866e7eafcf6aeb052a4d190dce38c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123337
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I58c1ef97fd6cba281c90cc7ed9917e04b7f265ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123187
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibd0b983d46a5683df64b4de79cd444427705e9e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123118
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
after
commit 503ab1ca9ae11978d9717557546c01ff598aaf88
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Sat Oct 2 16:28:56 2021 +0200
Use placement new to avoid one of the allocation calls...
Change-Id: I2eb85c5c1be5d2eaf757d717f03873415e49c9a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123083
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id88532da843e659d337f3529333a17a0c00c8328
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123050
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...when cloning a SfxItemSet.
Change-Id: I344fee3863006066eade16db9df37599fc210be3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123001
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
remove some of the naming limitations, and handle pointer parameters
better.
I only let the plugin run up till vcl/
Change-Id: Ice916e0157031ab531c47f10778f406b07966251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122892
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|