| Age | Commit message (Collapse) | Author |
|---|
|
also fixes the typo in the fMaxPassStrengthEntropyBits variable name.
Change-Id: I7c9cfcea7253a3e07428c83008b0c072033f33c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160425
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
and
cid#1546474 COPY_INSTEAD_OF_MOVE
cid#1546473 COPY_INSTEAD_OF_MOVE
cid#1546469 COPY_INSTEAD_OF_MOVE
cid#1546467 COPY_INSTEAD_OF_MOVE
cid#1546458 COPY_INSTEAD_OF_MOVE
cid#1546448 COPY_INSTEAD_OF_MOVE
cid#1546446 COPY_INSTEAD_OF_MOVE
cid#1546441 COPY_INSTEAD_OF_MOVE
cid#1546424 COPY_INSTEAD_OF_MOVE
cid#1546377 COPY_INSTEAD_OF_MOVE
cid#1546374 COPY_INSTEAD_OF_MOVE
cid#1546352 COPY_INSTEAD_OF_MOVE
cid#1546334 COPY_INSTEAD_OF_MOVE
cid#1546328 COPY_INSTEAD_OF_MOVE
cid#1546310 COPY_INSTEAD_OF_MOVE
cid#1546303 COPY_INSTEAD_OF_MOVE
Change-Id: I8a43fdd574857ba1d3ec416f23c8269a9a08e12f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160515
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and rename it to ScItemPoolCache,
since its only use is to handle ScPatternAttr objects
Change-Id: I68a2dd5f47fcf902f9df552e1a1767d5061d85d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160162
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It is not possible to use implCreateItemEntry/implCleanupItemEntry,
that is tooling limited *by purpose* to svl/Item/ItemSet stuff.
But what I can do is to do that SfxPoolItemHolder I already
talked/thought about. It is a helper that can safely hold a
SfxPoolItem in cases where an SfxItemSet is too expensive.
Think about it as a SfxItemSet for a single item. That solves
the problem why DirectPutItemInPool/DirectRemoveItemFromPool
is used in general (each usage is a 'compromize').
Did that now, works well. Editengine is now free of
DirectPutItemInPool/DirectRemoveItemFromPool.
Replaced ::CursorMoved with checkAndDeleteEmptyAttribs since all
these got static with no longer need to DirectRemoveItemFromPool.
Corrected create/delete counters.
Change-Id: Ia6e53f48ac2e479b461546515e68697039b5b628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159931
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I55c85a02e9dfc7d7cd2aaaec726fc5877a847264
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159849
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I572a7c81130f15929536c3c334875e8401be9e60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159700
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
That allows to not create a local copy on the heap before
being able to check if a change is really necessary
Also added mfOrientation to Cell::operator==, it was missing. Maybe
with C++20 we should more use the default generated op== (or op<=>)
that may turn out to be more safe. For class Cell at least all members
(and sub-members of Style) are simple and simple comparable.
Change-Id: Idea2ef2abe68c4bb14aa776a8393ba5da92abd5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159798
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Removed some special stuff in the ItemSet/Item tooling regarding
ScPatternAttr. There are still quite a view (grep for
isExceptionalSCItem), but all these are identified and isolated.
Only for that Item (of over 500) are these exceptions, so that raelly
does not fit into the Item schemata in any way. Not even the pool
default of ScPatternAttr is without trouble. It is the only and last
Item that needs to be 'pooled' in the sense to avoid copies on any
price. That is OK, but should not be done in the ItemSet schemata.
In short: It should not be an Item at all. It should be changed
and renamed to something describing it's role (CellAttributes..?)
and get helped/assisted by something called CellAttributeHelper at
SC's model or Pool. It should not even be derived from SetItem, it
could just contain an shared_ptr of SfxItemSet (allows more and better
optimizations - think about Clone() and op==).
In parallel, all these hacks in the ItemSet/Item stuff could be
removed, making that faster and easier. Also quite some usages of
DirectPutItemInPool could be cleaned-up, this only exists since
there *is* no defined place to hold that data (coud be
CellAttributeHelper in the future). Putting Items directly to the
pool (and in most cases never remove them again) is just nonsense
and another hint that all this does not fit to the Item/ItemSet
schema at all.
This is now - after hard isolation of problems and have all working -
doable. It may be one of the next things to do, but there are
other candidates, too. Doing this would mostly only help SC...
Found another hack that uses DirectPutItemInPool and *never* removes
any Item again, see comments framelinkarray.cxx
And another one: PoolItemTest::testPool() explicitely tests
DirectPutItemInPool stuff - which makes no sense long-term,
but for now keep it and make it work by marking the slots used
as _bNeedsPoolRegistration == true
Have now overhauled the framelinkarray stuff to work without
DirectPutItemInPool and Cell not being a SfxPoolItem. That will
be much less complex and use much less calls/checks. Since this
is the data structure created for every calc repaint that should
get faster, too.
Also for now and memory loss security I added code to
DirectPutItemInPool to behave the same as with the unchanged
implCreateItemEntry: register Items so that the garbage collection
still is used. This will/can be removed when all usages of
DirectPutItemInPool is cleaned up.
Directly registering in DirectPutItemInPoolImpl is more tricky
than thought, but a good thing to do. Looking at that I saw that
tryRegisterSfxPoolItem is not used anymore, so rearranged some stuff.
Change-Id: If07762b0a25e2739027f81872441772dc82a25d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159685
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ia74b15213a05da36f48932811d70d231ec7ee164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159673
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Due to the paradigm item change the test
make CppunitTest_sc_tablesheetobj
with CPPUNIT_TEST_NAME
sc_apitest::ScTableSheetObj::testSheetCellRangeProperties
got much slower. Unfortunately it did not break, so got unnoted.
I took a look now. First I intended to add some hashing in an
std::unordered_set using that hash values at ScPatternAttr, but
that is not even possible due to other data in that item that needs
to be compared. I had the impression that it was 'somehow' hashed
before, but after debugging the version before that change I
noted that also the list of existing items was linearly compared
to the new entry, using the operator==.
Thus the problem was not due to not hashing, but due to the
ScPatternAttr::operator==. That uses the hash (not changed),
but no longer finds equal entries.
This is because the hash code is made up from the SfxPoolItemPtrs
in the SfxItemSet, so when all are equal we can be sure the SfxItemSet
content is equal.
To use this the other way around is *not* correct: Even with
not all ptrs equal the SfxItemSets can still be equal, simply
by one SfxItemSet using another, but identical incarnation of
an item. Thuis means that ScPatternAttr::operator== does not
detect all cases of equality.
This worked in most cases before since most items were
'pooled' and thus much effort was used to ensure their uniqueness,
but even before the paradigm item change an item type could be
flagged as non-poolable. In that case, this already could fail
but with no too bad consequences (just one more copy of
an ScPatternAttr would stay).
So I fixed that mainly in adapting and optimizing
ScPatternAttr::operator==. The results are (same machine, same
compiler, dbg version, metioned test):
Version before item paradigm change:
user 0m50,778s
Version after item paradigm change:
user 20m13,944s
Version with memcmp:
user 0m48,845s
Version with hash:
user 0m48,710s
Since that hash does nothing else than to buffer the comparison of
those item pointers I just tried to use memcmp instead, as is already
used in other places (same file, ScPatternAttr::FastEqualPatternSets,
also SfxItemSet::operator==). As can be seen above it makes practically
no difference (memcomp even slightly faster).
Since that hash is only used in ScPatternAttr::operator== and is same
speed (memcomp linearly compares 56 SfxPoolItem ptrs) I decided to
remove it. It needs quite some spaces to be reset and re-calculated
which are not needed anymore. The calculation is based on dividing
the number of items by 4, so we are good with 56, but if someone has/
will adapt the items used by ScPatternAttr it is easy to forget to
adapt this, and not easy to change the alghorithm when it's not a
multiple of 4.
I also optimized/overhauled SfxItemSet::operator== (or better: the
SfxItemSet::Equals used by it). It is now better readable, too.
I also adapted ScAttrArray::AddCondFormat to not always incarnate/
delete ScPatternAttr instances, only when needed. This also helps
a bit and could be done in more places.
All in all it is really necessary to cleanup SC's usage of
ScPatternAttr - there are quite some possibilities to make that
cleaner and faster. In principle it's a huge 'compromize' to use
item functionailty to have a possibly 'cheap' maximum shared
SfxItemSet at a Cell.
Decided to make SfxItemSet::operator== even faster for the case
of unequal ranges by iterating over ranges of local SfxItemSet
and incremented offset. Still accesses to 2nd SfxItemSet will be
the expensive ones using the iterated WhichID.
Added two more things to SfxItemSet::operator==: We can return
early when both have no items set. For the unequal-ranges compare
I added an early-exit when Count() items were compared.
Looked at the errors that indeed do trigger the assert in
ScPatternAttr::operator== and hint to incarnations of ScPatternAttr
that do not use the needed range ATTR_PATTERN_START, ATTR_PATTERN_END.
Hunted down to come from ScViewFunc::ApplyAttributes and there from
some Dialogs, so seems some SC dialogs do not work with the correct
range schema for that item.
I tried code in ScViewFunc::ApplyAttributes to fix it, that works. I
also tried to hunt that down to the Dialogs that use the wrong schema
(TotalCount @SfxItemSet is 61 BTW). While it would be possible to do
so, it's no guarentee to have this fixed.
Thus I looked at ScPatternAttr::ScPatternAttr and added correciton
code when one with the wrong range schema gets created, this is
luckily not often needed and transfers the existing items with low
costs.
Maybe we should add a warning there if used, so at least new
implementations of stuff or old ones (the Dialogs) can be corrected?
Change-Id: I31da73ae30786bd6c5a08a5e3b7df8fe279af261
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159592
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Moves PasswordStrength bits that provide utility functions from cui to svl,
merging them with PasswordHelper there.
Adds password strength bar for the set master password dialog.
(accessible via Tools -> Options -> LibreOffice -> Security -> Passwords for Web
Connections)
Change-Id: I8dc1090a041f8388c2e139beb1d0d9a0beb8acb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159370
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
Change-Id: Ie61d6e5f77d3473e4e867bda7be9805ca1e355ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159410
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Places that didn't initialize it previously, would benefit automatically
Change-Id: I2f1ff25fc58d9378462072bc92d7b37be2370fc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159299
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7051d0df2f21bbd5ad22404bd7b72c15aba5b861
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159188
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I9423e9a6e796b8b0754d2f1c3d17ca99d325726c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159189
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...as reported by <https://ci.libreoffice.org/job/lo_ubsan/2973/> during e.g.
Gallery_backgrounds, when initializing the global variable
> const Cell OBJ_CELL_NONE;
at svx/source/dialog/framelinkarray.cxx:281,
> ==519895==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7fb3dc3e5570 at pc 0x7fb3daee1c56 bp 0x7ffe54584480 sp 0x7ffe54584478
> READ of size 8 at 0x7fb3dc3e5570 thread T0
> #0 0x7fb3daee1c55 in std::_Hashtable<SfxPoolItem const*, SfxPoolItem const*, std::allocator<SfxPoolItem const*>, std::__detail::_Identity, std::equal_to<SfxPoolItem const*>, std::hash<SfxPoolItem const*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::bucket_count() const /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/hashtable.h:673:16
> #1 0x7fb3daee1648 in std::__cxx1998::unordered_set<SfxPoolItem const*, std::hash<SfxPoolItem const*>, std::equal_to<SfxPoolItem const*>, std::allocator<SfxPoolItem const*> >::bucket_count() const /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/unordered_set.h:755:21
> #2 0x7fb3daeb1088 in std::__debug::unordered_set<SfxPoolItem const*, std::hash<SfxPoolItem const*>, std::equal_to<SfxPoolItem const*>, std::allocator<SfxPoolItem const*> >::insert(SfxPoolItem const*&&) /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/unordered_set:369:35
> #3 0x7fb3db01987c in SfxPoolItem::SfxPoolItem(unsigned short) /svl/source/items/poolitem.cxx:506:28
> #4 0x7fb3cb2fddb4 in svx::frame::(anonymous namespace)::Cell::Cell() /svx/source/dialog/framelinkarray.cxx:204:5
> #5 0x7fb3cafa3b6f in __cxx_global_var_init.1 /svx/source/dialog/framelinkarray.cxx:281:12
> #6 0x7fb3cafa3ba9 in _GLOBAL__sub_I_framelinkarray.cxx /svx/source/dialog/framelinkarray.cxx
> #7 0x7fb3e6821f19 in call_init.part.0 /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:72:3
> #8 0x7fb3e6822019 in call_init /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:118:11
> #9 0x7fb3e6822019 in _dl_init /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:119:5
> #10 0x7fb3e6836cb9 (/lib64/ld-linux-x86-64.so.2+0x1dcb9)
>
> 0x7fb3dc3e5570 is located 48 bytes inside of global variable 'incarnatedSfxPoolItems' defined in '/home/tdf/lode/jenkins/workspace/lo_ubsan/svl/source/items/poolitem.cxx:473:47' (0x7fb3dc3e5540) of size 96
> registered at:
> #0 0x43c078 in __asan_register_globals.part.0 /home/tdf/lode/packages/llvm-llvmorg-12.0.1.src/compiler-rt/lib/asan/asan_globals.cpp:360:3
> #1 0x7fb3db01e7cb in asan.module_ctor (/instdir/program/libsvllo.so+0xb3c7cb)
Change-Id: I490fb232e0944f18c49b734c621e1bf0c318baff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159120
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
To understand this, some look back in history will be needed to see
why it is as it is today. In some (reworked) comments 'poolable' is
described as flag to hold Items in the ItemPool, also always having
only one incarnation of each possible Item.
This is not the original intention, but a side-effect. The reason is
what the binary format in the office did: To save a document, the
Objects & the Pool were saved, *not* individual Items *together*
with the objects. The Pool was completely (binary) saved (and loaded)
in one run.
Temporary IDs were used to represent at the objects in file which
Items were referenced. This *required* to have only one incarnation
per item to have a minimal binary file size, thus this high effort
was put into this. At doc load, the pool was loaded, all Items were
set to RefCount 5000, the references from the objects were restored
and then for each Item the RefCount was lowered by 5000 again
and - if being zero - deleted. Items for UI were marked 'non-poolable'
to *not* safe them with the document, so poolable was a flag to decide
if that Info/Item was to be saved with the document - or more direct:
if it is Model Data.
Items are small, so if we prefer runtime it is okay to no longer being
strict with this, anyways does not happen often and has only marginal
memory effects - compared to runtime effects/savings.
Other problems which this caused: One example is that objects in the
UNDO stack were still in the pool, so e.g. deleted pictures were saved
with the document despite no longer being used (!). That is the reason
we have an UndoItemPool and a method MigrateItemPool to move stuff to
that Pool when objects go to the UNDO stack - all of this is also no
longer needed.
Cleaning this up means to ideally have all items in the SfxItemSet,
no longer at the Pool. The Pool should be reduced to a 'Default-Item-
Holder' and a 'Slot-to-whichId-mapper'.
This needs thorough cleanups/removals, but will be worth it because
that massive simplification(s) will increase safety an runtime and make
migrating to the goal of completely type-based ItemSet stuff easier for
the future. Hopefully only view code in the office working with items
will have to be changed for this.
In this 1st step I already found that some 'compromizes' will be
needed:
- There are still Items that have to be at the pool to make the
Surrogate-stuff working. This gives back all Items in a Pool of a type
and is used in ca. 80 cases. Each one looks at these Items *without*
context (e.g. a SfxItemSet at an Object would be a context), so if e.g.
a dialog is open that temporarily uses Items of that type you would
also get these - without knowing about it...
To make that work there is still a mechanism to have Items at the Pool,
but now just *registering* (and un-reg) them without any sort/search/
remove needs. Also only for Items that need that, so I evaluated the
GetItemSurrogates calls and added some asserts when GetItemSurrogates
tries to access an unregistered item type which needs to be added.
- Another caveat is that there are about 250 places that directly put
Items to the Pool (not all remove these, that is done at pool deletion,
so some kind of silent 'garbage-collection' is in place). To have an
overview I renamed the accessing methods to separate them from the same
functionality at the SfxItemSet, which had the same names. An
implementation does still add these directly to the pool, there is no
way to cleanup those usages for now. In principle all these should be
changed to hold the data at an SfxItemSet.
I am still hunting problems. But you can build the office, all apps
work (including chart) and you can do speed comparisons already.
There are test throwing errors, so I hunt these now. It is hard to
give an estimation about how much more changes/corrections will be
needed.
Completed adaptions to new registered Items at Pool, that reduces the
failing tests. Still many that I need to hunt.
Added stuff to work around that 'compromize' in ScDocumentPool: It
overloads ::PutImpl of the pool to implement special handling for
a single Item in SC, the ScPatternAttr. In former code that method
was used from SfxItemSet and ::PutImpl at the pool directly, so it
was only used in one place. I am not sure if it was used from
the SfxItemSet functionality, but better offer it for now. To not
waste too much runtime the callbacks depend on the boolean
'NewItemCallback' at the SfxPoolItem, it gets set for that single
Item in SC and only then the callbacks trigger. I hope to get rid
of those again, e.g. newItem_UseDirect is only needed since we have
no 'real' StaticPoolDefaults currently - another thing that needs to
be cleaned up in a next step.
Since usages of impl(Create|Cleanup)ItemEntry and
Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to
unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it
globally available in svl and use it also directly for
Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing
tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that
fallback (e.g. tryToGetEqualItem) was used before, thus this is the
same class of errors (SfxPoolItem ptr-compare) as the others which I
will need to find anyways. Also fixed some missing stuff.
Have now idenified and redirected all SfxPoolItem ptr-compares
to be able to debug these - one cause for the remaining errors is
probably that before with bPoolable those often were sufficient, but
are no longer. Used the [loplugin:itemcompare] and a local clang
build to do so, see https://gerrit.libreoffice.org/c/core/+/157172
Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter
to implCreateItemEntry to signal that it gets called from DirectPool
stuff - currently needed. Hopefully when getting rid of that DirectPool
stuff we can remove that again
Added two more debug functionalities:
- Added a SerialNumber to allow targeted debugging for deterministic
cases
- Added registering & listing of still-allocated SfxPoolItems at
office shutdown
Found PtrComp error in thints.cxx - POC, thanks to
areSfxPoolItemPtrsEqual. Will hopefully help more with other tests
Found some wrong asserts/warnings where I was too careful and not
finding something/succeeding is OK, fixes some UnitTests for SC
For SC I now just tried to replace all areSfxPoolItemPtrsEqual with
the full-ptr-content compare SfxPoolItem::areSame. I also needed to
experiment/adapt the newItem_Callback solution but got it working.
Did that replacement now for SW too, found some places where the
direct ptr compare is OK.
Continued for the rest of occurrences, now all 160 places evaluated.
Also done some cleanups.
Massive cleanups of stuff no longer needed with this paradigm change.
Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now.
It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that
already needs many exceptions. Also useful for testing if errors
come up on this change to test if it is related to this.
Added forwarding of target Pool for ::Clone in SvxSetItem and
SvxSetItem, simplified SfxStateCache::SetState_Impl and returned
to simple ptr compares in SfxPoolItem::areSame to not do the test
in areSfxPoolItemPtrsEqual.
Debugged through UITest_calc_tests9 and found that in tdf133629
where BoxStyle is applied to fully selected empty calc the Item-
reuse fallback has to be used not only for ATTR_PATTERN, see
comment @implCreateItemEntry. Maybe more...
Problem with test_tdf156611_insert_hyperlink_like_excel. Found that
in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField
is found and returned as ptr, but it's usage crashes. That is due to
the SfxItemSet aEditSet used there gets destroyed at function return
what again deletes the SvxFieldItem that is holding the SvxURLField
that gets returned.
This shows a more general problem: There is no 'SfxPoolItemHolder'
that safely holds a single SfxPoolItem - like a SfxItemSet for a
single Item (if Items would be shared_ptrs, that would be a safe
return value).
That will be needed in the future, but for now use another solution:
Since I see no reason why EE_FEATURE_FIELD should not be shareable
I wil change this for ow in the SfxItemInfo for EditCharAttribField.
That way the Item returned will be shared (RefCnt > 1) and thus not
be deleted.
I changed the return value for GetURLField() and
GetFirstURLFieldFromCell() in ScEditShell: At least for
GetFirstURLFieldFromCell the return type/value was not safe: The
SvxFieldItem accessed there and held in the local temporary
SfxItemSet may be deleted with it, so return value can be
corrupted/deleted. To avoid that, return a Clone of SvxFieldData
as a unique_ptr.
With all that UnitTest debugging and hunting and to get the paradigm
change working to no longer rely on shared/pooled items I lost a
little bit focus on speed, so I made an optimization round for the
two central methods implCreateItemEntry/implCleanupItemEntry to
get back to the speed improvements that I detected when starting this
change. It was mainly lost due to that 'strange' chained pool stuff
we have, so I added to detect the target pool (the one at which the
WhichID is registered) directly and only once. Next thing to cleanup
will/should be the pool and it's concept, all this is not needed
and really costs runtime.
Since implCreateItemEntry/implCleanupItemEntry are executed millions
of times, each cycle counts here.
Had an error in the last changes: pool::*_Impl methods use index
instead of WhichID - most of them. Another bad trap, I really need
to cleanup pool stuff next.
Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
The problem is that curl 8.3.0 removed the NSS backend, so we now
have no other choice than to use the bundled OpenSSL on Linux.
Currently any curl https connection fails with:
CurlSession.cxx:963: curl_easy_perform failed: (60) SSL certificate problem: unable to get local issuer certificate
Apparently this requires manually telling curl which CA certificates to
trust; there is a configure flag --with-ca-bundle but that is useless as
it tries to load the file relative to whatever is the current working
directory, and also did i mention that there are at least 3 different
locations where a Linux system may store its system trusted CA
certificates because ALL ABOUT CHOICE.
So add a new header with an init function to try out various file
locations listed in this nice blog article and call it from way too many
places that independently use curl.
https://www.happyassassin.net/posts/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/
TODO: perhaps bundle a cacert.pem as a fallback in case the system chose
to innovate by putting its certificates in yet another unexpected place
(regression from commit c2930ebff82c4f7ffe8377ab82627131f8544226)
Change-Id: Ibf1cc0069bc2ae011ecead9a4c2b455e94b01241
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158915
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I005257e458351285b1b35ffe49c8b42834a6db68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156990
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Exponent in scientific number may use '?' as blank like in format "0.00E+?0"
This change:
- adds interpreatation of '0' and '?' in exponent
- adds "blank-exponent-digits" attribute to scientific number for import
and export to ODF
- prevents using exponent with only '?'. There must be at least one '0'
in exponent
- adds QA test of such format and test import/export/import to ODF and OOXML
- corrects one basic test
Change-Id: If52edc632a161f842270bb2fd77af535e2b978d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154986
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
|
|
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I31d46c2b75888474136ecd630fd3f817db189fb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158223
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
regression from
commit 49dd32a88d90097a1c50dc64dc42dc35645780b8
author Noel Grandin <noel.grandin@collabora.co.uk>
osl::Mutex->std::mutex in PasswordContainer
Change-Id: Ie6270f6ed47ee892181f7b9e51ed8ef75533f4e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: If25dcbb9784c041b61fe9aaea213035a4769962b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157397
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
...that use internally an sw::BroadcastingModify*. This caused
an error/crash with the testfile ooo58307-1.sxw, thanks to
Caolan to find it. For BG info please see comments in
the changed sw/source/core/attr/swatrset.cxx
Change-Id: Ia91fff19ffb39873c7e2bd5ff8806b95fc5ac7ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157383
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Added a counter for SfxItemSet usages, similar to the
already added one for SfxPoolItems to allow quick info
about evtl. problems/drawbacks of changes.
Replaced enum SfxItemKind in favour of settable boolean flags
directly at SfxPoolItem. These are organized as bitfield, do
not need more space as the enum and allow to be set separately
and multiple ones at the same time.
Flags for PoolDefault/StaticDefault/DeleteOnIdle use this now
and are quickly accessible booleans. It is not a problem that
theoretically the flags for PoolDefault/StaticDefault could now
both be set - this is internal to SfxItem stuff and not accessible
from normal code, so can be managed.
Added for debug build a bitfield boolean m_bDeleted
that will be set in the SfxPoolItem destructor. Of course
it's usability will depend on the freed space not yet being
re-used, but will hopefully help in the debugger to detect
reasons for failure (would have helped at least me before).
Added for replacement of virtual method IsVoidItem() another
bitfield bool m_bIsVoidItem that is set in the constructors
of SfxVoidItem. Also had to add some constructors to do that
which were defaulted before. This is mainly because the base
class SfxPoolItem does *not* have a copy-constructor that
copies the members (flags/RefCnt/WhichID) and we should keep
that 'indirect reset' when Cloning. isVoidItem() is now a simple
boolean member access - the bitfield does the needed masking.
This spares one entry in the virtual function table of
SfxPoolItem which is derived more than 500 times.
Used the results of the experiment at
https://gerrit.libreoffice.org/c/core/+/156774 to change
some accesses to IsVoidItem() to use SfxItemState instead.
This is for preparation of splitting up the two usages of
SfxVoidItems, see commit text in the experiment.
If this shows problems in the future those six places documented
there may have to be changed back to use the new isVoidItem(),
but should also check the ptr this time to be non-zero.
Removed SFX_ITEMS_SPECIAL that is no more used anywhere.
Change-Id: Ib687ca2362d72a4651c75aee0c67029088f68947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156805
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I89d3a3074929ba867975ae57d350b7e4211ed67c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156757
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I88d79ca31981a49736af571067831c703cf65d3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156755
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I1a853bec38ce31d7961a150d4f3958c38c896559
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156756
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Icf7b6216180fe259cc9c529ea5c48720324c9262
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156759
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Again this is a change to improve understandabilty/changeability
of SfxItemSet code plus some cleanups. Still did a callgrind round
to check - it slightly got faster. In a start/load(complex SW doc)/
show/shutdown cycle compared with master I get 96.722 mio cycles
compared with 99.851 mio in master.
Main focus was to isolate two aspects: preparation and cleanup of
an Item for usage in an SfxItemSet. For that we now have
implCreateItemEntry: to do all needed actions to create/prepare
an Item for membership, including evtl. AddRef/Cloning/using
ItemPool stuff.
implCleanupItemEntry: to do all needed actios to correctly
clean that Item up again.
All formally accesses distributed over SfxItemSet (and other places)
are cleaned-up to use these. The Item-counter in DBG code that I
already added helped a lot to do this.
Also cleaned up PutImpl to 1st check if action is necessary (Item is
already in place) or not, reducing spot to cleanup an Item that
was handed over as bPassingOwnership to one place.
I also added a 2nd flag, bItemIsSetMember, that tells if the Item
given as input is already member of an SfxItemSet, in that case a
shortcut can be used (increase AddRef, use).
Adapted all places AFAP to use the new container interface
(begin(), end(), ...) where useful.
Made GetItemState inline and directly use the tooling method. Same
for InvalidateItem.
Added much more comments to describe what's going on or to hint at
problems (check for CAUTION).
Removed PutDirect - not needed anymore, probably was there to not get
recursive death loop with callbacks in SW.
More smaller changes.
Checked with all apps, played around. Still, stuff may come up, so
I put on gerrit the tests will show and give further hints. At last
SfxItemSet is a minefield :-)
Had to adapt SfxItemSet::implCreateItemEntry when input Item is
a StaticDefaultItem. SfxItemPool::PutImpl needs to be called in
that case.
Had to correct bItemIsSetMember in all cases if the transfer
of SfxPoolItems is between SfxItemSets with different
SfxItemPools. This is and will be necessary as long as the
Items are stored at the pool.
After a hard deep-dive I found the error: m_nCount was not in
all cases correct, invalid items get counted.
Win build *insists* for initialzation of local var aEntry in
SfxItemSet::PutImpl, triggers warning C4701:
"potentially uninitialized local variable 'aEntry' used". This
is not the case here, but I know of no way to silence the
warning in another way, so added an extra-call to begin().
Re-added to use static pool defaults directly, possible After
the fix 6d8c6e8d60956fd36094035a526c1a29a902204b, thanks for
that. This avoids some cloning of Items.
CAUTION: static default items are not *that* static as it seems
(or: should be). If they are freed with the Pool (see
::ReleaseDefaults) they will be deleted. If the target pool is
different from the source pool static default items from the
source pool can be used that then might be deleted (sigh).
A solution would be to change all pools to really work on
static instances of default items.
Another one would be to know here that the
targetPool != sourcePool, so maybe extend
bItemIsSetMember -> bSamePool.
A good test for this is CppunitTest_chart2_uichart/testTdf98690.
Until solving/cleaning up we unfortunately *have* to continue
to clone static default items...
Change-Id: Ibd8dc6d612f594a5ad88c75fcee8726d89a6090c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156306
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Iabecd5b4cff803e45fede6b25db03d553eb835a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156651
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This change is not about speed improvements but diverse
preparations to make changes/reading/understanding easier.
It does not change speed AFAIK.
Added a global static debug-only counter to allow getting
an overview over number of all allocated SfxPoolItem's
and the still alloated ones at office shutdown. The values
are used in Application::~Application to make a short info
statement. It allows to be able to quickly detect if an
error in future changes may lead to memory losses - these
would show in dramaitically higher numbers then (hopefully)
immediately.
Moved SfxVoidItem to own source/header.
Added container library interface support to SfxItemSet,
adapted already some methods to use it - not all possible,
I will commit & get status from gerrit 1st if all still works
and then continue.
Changed INVALID_POOL_ITEM from -1 to use a global unique
incarnation of an isolated derivation from SfxPoolItem. It
allows to avoid the (-1) pointer hack. Since still just
pointers are compared it's not worse. NOTE: That way, more
'special' SfxPoolItem's may be used for more States - a
candidate is e.g. SfxVoidItem(0) which represents ::DISABLED
state -- unfortunately not only, it is also used (mainly for
UI stuff) with 'real' WhichIDs - hard to sort out, will have
to stay that way for now AFAIK.
Changed INVALID_POOL_ITEM stuff to use a static extern
incarnated item in combination with a inline method
to return it, called GetGlobalStaticInvalidItemInstance().
Isolated create/cleanup of a SfxPoolItem entry in
SfxItemSet to further modularize/simplify that. It is
currently from constructor & destructor but already shows
that PoolDefaults are handled differently - probably an
error. Still, for now, do no change in behaviour (yet).
Got regular 'killed by the Kill-Wrapper' messages from
gerrit, seems to have to do with UITest_sw_findReplace.
That python/c++ scripting stuff is hard to debug, but
finally I identified the problem has to do with
the INVALID_POOL_ITEM change. It was in
SfxItemSet::InvalidateAllItems() where still a (-1)
was used -> chaos in detecting invalid items.
Change-Id: I595e1f25ab660c35c4f2d19c233d1dfadfe25214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155675
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
regression from
commit 7c66fc45239d2589e90fd694d54b3ff826b1bd15
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Jun 1 14:22:57 2023 +0200
use internal iterator for SfxBroadcaster
Change-Id: Ibd3abf23337c8fb0937d245474f2b89c8936a3ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When browsing cachegrind data I stumbled over the notification
callback used by Writer in SfxItemSet::Changed. That is a
virtual method that gets called in quite some places to forward
item changes, SW uses it to record these.
For that purpose always (quite some) data gets prepared without
checking if this is necessary, this uses calls to ::Get and
::GetDefaultItem to have either the old or new Item from the
parent or default (pool).
This is not needed - except for Writer. Even there this
mechanism is not always active. Thus I:
- removed SfxItemSet::Changed, replaced with a settable callback
member of type std::function<...>. Thus one less virtual function
and depenence in SfxItemSet
- added a callback functor to SwAttrSet that can be set at the
SfxItemSet it is derived from
- setting/releasing this only in used cases. It is not even used
all the time in SW.
- moved the creation/processing of needed data to a member
function in SW (SwAttrSet::changeCallback). All processing and
evtl. needed data is now created there - on demand.
- adapted all places in SfxItemSet where that mechanism is used
to only call it if set & without pre-calculating anything
- since all former calls/usages were pretty similar I could put
all of this to SwAttrSet::changeCallback
This leads to use that only when needed now. Naturally, SW will
potentially profit less than the other apps.
Here are callgrind numbers with this change using OfficeStart,
DocLoad, DocClose, OfficeShutdown. This change also has potential
avantages @runtime/UI which also did all preparations to call
SfxItemSet::Changed all the time:
Writer doc: 0,9907 ~1%
old: 93842 mio
new: 92971 mio
Draw/Impress doc: 0,9971 ~2,8%
old: 170023 mio
new: 169544 mio
::Get reduces from 1416103 to 293874 calls
::GetDefaultItem reduces from 2252336 to 1927209 calls (nearly half)
Calc doc: 0.9868 ~1,3%
old: 194708 mio
new: 192130 mio
::Get reduces from 882298 to 880087 calls
::GetDefaultItem reduces from 4611901 to 2633555 calls (nearly half)
Of course this highly depends on the used test documents, so it can
only be a excerpt result.
Also adapted SfxItemSet::MergeRange a little bit: Do nothing not only
when a single new slot is already contaioned, but check if all slots
are already present. This works well and fast using the formally added
caching mechanism.
Change-Id: I4d369d2e5b21aa7a21687177518150515e3de954
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: If6cdd69d4508cc938ee90f286b2a6103f24a917b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155430
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
I checked for was to speedup SfxItemSet stuff, so had
(besides other things) a look at WhichRangesContainer
and it's usage(s). Problem with the WhichRanges is that
a WhichID which you try to find is usually inside that
range, so binary search is no option. You have to detect
in which range the WhichID is hosted and can the directly
calculate the index into the array of Items at the
SfxtemSet.
Currently when needing to transform a WhichID to an index
into the array of Items in SfxItemSet the array of the
WhichRangesContainer is searched linearly from the start
every time.
This can be a little bit speed up by buffering the last
successful 'hit' and trying to re-use it. Also the
special case of a single WhichPair (e.g. UI stuff) is
worth having a look.
All acesses to that transformation are changed to use
the tooling method getOffsetFromWhich() at the
WhichRangesContainer which does the transformation.
This also needed cleanup of ItemOffsetHint instances
& stuff around it. It does not more than before but
also profits from the single entry buffer.
I added some DBG_UTIL-based stuff to watch the hit/miss
ratio, which is heavily changing from app to app & usage,
but varies around 1.5 to 3.5, also saw 6.5 and more at
document import.
NOTE: I already checked if sorting the WhichPair(s) in
WhichRangesContainer by their 'width' (highest WhichID
mnius lowest WhichID helps. The idea was when the Items
would be used in a regular manner that when having the
widest WhichPairs at the start, the buffer would even
be better used - but doing tests in all apps shows
nearly no gain, so I left that out.
NOTE: Not too much speedup, but faster...
Had to deep-debug due to CppunitTest_sw_odfexport failing,
found a slight diff between GetItemState impls, corrected.
Also added more changes, e.g. TotalCount is now a member
to not always have to calculate it from the
WhichRangesContainer.
Extended GetWhichByPos to 1st try to find a set Item, else
iterate over WhichRangesContainer.
This is due to SfxItemIter's implementations of
GetItemState and ClearItem which both up to now just
accessed the SfxPoolItem array of the SfxItemSet, ignoring
that no Item (nullptr) or state DONTCARE (-1) may have been
set there (no item is prevented by ite Iterator, but better
be careful).
Added WhichRangesContainer::getWhichFromOffset and made
SfxItemSet::GetWhichByOffset use it. Addedd optimizations
there for single-entry WhichPair and using the buffer at
WhichRangesContainer which is possible.
Removed debug comparing stuff (had a test that used the
former adapted GetItemStateImpl method in
SfxItemSet::GetItemState and compared with the changed
GetItemState_ForWhichID).
Added some comments and assertions where useful.
Made ClearSingleItem_ForOffset work without handing
over WhichID, that makes calls using it simpler and
avoids calculating the WhichID just for that call.
Change-Id: I54de552368b654f00f115978715f8241eb603752
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155316
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
- also remove now obsolete GetInfo overrides
Change-Id: Iaac75ed2e53daead06242ce4620fd2b879909e02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155061
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
|
|
...as witnessed with patch set 1 of
<https://gerrit.libreoffice.org/c/core/+/155121/1> "Bump baseline to C++20",
> In file included from /opt/rh/gcc-toolset-12/root/usr/include/c++/12/bits/char_traits.h:46,
> from /opt/rh/gcc-toolset-12/root/usr/include/c++/12/ios:40,
> from /opt/rh/gcc-toolset-12/root/usr/include/c++/12/ostream:38,
> from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/include/rtl/ustring.hxx:34,
> from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/include/svl/gridprinter.hxx:13,
> from /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/svl/source/misc/gridprinter.cxx:10:
> In function ‘constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*, _Args&& ...) [with _Tp = long unsigned int; _Args = {const long unsigned int&}]’,
> inlined from ‘static constexpr void std::allocator_traits<std::allocator<_CharT> >::construct(allocator_type&, _Up*, _Args&& ...) [with _Up = long unsigned int; _Args = {const long unsigned int&}; _Tp = long unsigned int]’ at /opt/rh/gcc-toolset-12/root/usr/include/c++/12/bits/alloc_traits.h:518:21,
> inlined from ‘constexpr void std::vector<_Tp, _Alloc>::_M_realloc_insert(iterator, _Args&& ...) [with _Args = {const long unsigned int&}; _Tp = long unsigned int; _Alloc = std::allocator<long unsigned int>]’ at /opt/rh/gcc-toolset-12/root/usr/include/c++/12/bits/vector.tcc:462:28,
> inlined from ‘constexpr void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = long unsigned int; _Alloc = std::allocator<long unsigned int>]’ at /opt/rh/gcc-toolset-12/root/usr/include/c++/12/bits/stl_vector.h:1287:21,
> inlined from ‘mdds::mtv::soa::multi_type_vector<Traits>::iterator mdds::mtv::soa::multi_type_vector<Traits>::set_cell_to_empty_block(size_type, size_type, const T&) [with T = rtl::OUString; Traits = mdds::multi_type_matrix<svl::{anonymous}::matrix_traits>::mtv_trait]’ at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/mdds/include/mdds/./multi_type_vector/soa/main_def.inl:2995:50,
> inlined from ‘mdds::mtv::soa::multi_type_vector<Traits>::iterator mdds::mtv::soa::multi_type_vector<Traits>::set_impl(size_type, size_type, const T&) [with T = rtl::OUString; Traits = mdds::multi_type_matrix<svl::{anonymous}::matrix_traits>::mtv_trait]’ at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/mdds/include/mdds/./multi_type_vector/soa/main_def.inl:1240:72,
> inlined from ‘mdds::mtv::soa::multi_type_vector<Traits>::iterator mdds::mtv::soa::multi_type_vector<Traits>::set(size_type, const T&) [with T = rtl::OUString; Traits = mdds::multi_type_matrix<svl::{anonymous}::matrix_traits>::mtv_trait]’ at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/mdds/include/mdds/./multi_type_vector/soa/main_def.inl:696:14,
> inlined from ‘void mdds::multi_type_matrix<Traits>::set(size_type, size_type, const string_type&) [with Traits = svl::{anonymous}::matrix_traits]’ at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/UnpackedTarball/mdds/include/mdds/multi_type_matrix_def.inl:356:5,
> inlined from ‘void svl::GridPrinter::set(size_t, size_t, const rtl::OUString&)’ at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/svl/source/misc/gridprinter.cxx:68:25:
> /opt/rh/gcc-toolset-12/root/usr/include/c++/12/bits/stl_construct.h:97:14: error: array subscript 0 is outside array bounds of ‘long unsigned int [0]’ [-Werror=array-bounds]
> 97 | { return ::new((void*)__location) _Tp(std::forward<_Args>(__args)...); }
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(<https://ci.libreoffice.org/job/gerrit_linux_gcc_release/148699/>), etc.
(The curly braces in sw/source/core/doc/doc.cxx had to be added to avoid an
ensuing bogus
> sw/source/core/doc/doc.cxx: In static member function ‘static void SwDoc::CalculatePagePairsForProspectPrinting(const SwRootFrame&, SwRenderData&, const SwPrintUIOptions&, sal_Int32)’:
> sw/source/core/doc/doc.cxx:1000:5: error: ‘else’ without a previous ‘if’
> 1000 | else
> | ^~~~
)
Change-Id: I902f6d74d897b9bf281dc9c821aff30e7e72582a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155215
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
since
commit 519876dffdc8c93710af543cc11332dab9a50c14
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Tue Jul 18 23:45:47 2023 +0300
Cleanup SfxApplication::Get/SetOptions, and drop unused SIDs
Change-Id: I8d306bf6792630cfdaa0a0ac8b77730e1e1f0070
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The removed stuff was never used elsewhere; e.g. all uses of GetOptions
use Which Ranges that don't include the removed identifiers. Elements
removed from SetOptions weren't passed to that function from anywhere.
Change-Id: Id81b57014b82f89538a46a609f3e4b328864bbcf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154604
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I20e7c1082687d780eded364f2620dd0dcbe831ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154532
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
To be consistent with its other methods (Get/SetTextByPos),
taking sal_uInt16
Change-Id: I1c6e7c9fcb8bb6bf57d4ed4481240e0c7b606049
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154460
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
ever since
commit 5db72ef0b381671b7867bda759098a92909e06d8
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Jul 26 13:51:57 2021 +0200
drop SvtLanguageOptions class
Change-Id: I2d56b0c21510239ef1ee1d0b95748641d485580c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154053
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use SfxStyleSheetBase::SetParent directly instead. The
base class was just calling it anyway, while the
SwDocStyleSheetPool override was mostly a copy & paste
of its override in SwDocStyleSheet.
Change-Id: I18d8208ed2d079e0f2ce4f13a5dbdda6fe4730e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153773
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: I95ab7581dec35b113cb657ce8e5ee27c89c73593
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153746
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2cbc5dce800b773e6c20cb3ea6f0e520a3f69db9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153688
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
