| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I1835209f48896e01af2cb3fad10a758b704087dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169515
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I080533a791c8ad0034b4b24ea630c6ab7265e31e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169171
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I33b497fd707e5100d0a03cf9868b0627859922ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169178
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia64d863baa72a2d32a8bee40968af4f6aacd88bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167332
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I32f74fe67e8eb0b6b12ee60405c3d99932b75182
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167284
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I68acd56b28b0f989a4010cd939f2452970d158ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167103
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I498c10e8bc134b41e3606d8a05cf3103a9274735
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166937
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
where it was obsoleted by commits 2484de6728bd11bb7949003d112f1ece2223c7a1
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I4ccc647bb794515c8c11f8dfd9a26563f4aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166819
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I3581cc8eb2414161ecb81a4ebcedd7b3b391c642
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165571
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
...(that was defined iff OSL_DEBUG_LEVEL >= 2) and replace its uses with
OSL_DEBUG_LEVEL directly
Change-Id: I807c15a02cc8ced9852287df0afb4808761d19d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165067
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Icba230fedc9e6071d3817454f55d4533727e3aa2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163916
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:/lo/core/sw/source/ui/dbui/addresslistdialog.cxx(426): warning C4312: 'reinterpret_cast': conversion from 'int' to 'void *' of greater size
Change-Id: Idbfbe8add89c8e219bdabcf28b741e2e31a5e345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163781
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:/lo/core/oox/source/export/shapes.cxx(2411): warning C4459: declaration of 'XML_line' hides global declaration
Change-Id: I74738753254ad1c468025d25bfb0bfe21787180f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
With ItemInfoPackages we now can have a buffered, static
global translation table from SlotIDs to WhichIDs since
the ItemInfoStatic used already contains all the needed
information.
Register that in registerItemInfoPackage at the Pool and
use it for lookup. That speeds up the lookup from O(n)
to O(1). Since that lookup is used in UI and UNO API
implementations this has positive effect on load/safe,
but also all interactive stuff in the whole office.
NOTE: I tried to use a merged version of that translation
table in the parent pool, but this shows double SlotIDs,
what is no wonder since that's what those are used for:
To get different WhichIDs for a SlotID in Item handling.
This *might* prevent getting rid of the chanined Pools
at all - sadly. The returned WhichID directly depends
on which Pool the function(s) GetWhichIDFromSlotID and
GetTrueWhichIDFromSlotID are called.
NOTE: Very strange is that the parameter 'bDeep' in that
functions is *not* passed down to the call to the
secondary Pool - probably an error, but risky to fix,
that may change already the behaviour :-(
Change-Id: Iea77ffad0f6a5401ab74fea0bbfc2589c66680ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163597
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Secured usage of FontList in SvxFontListItem
usage (a test)
Change-Id: I412a7681b3ece4e5d3751165d4b566ccdf5b2da9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163257
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Driving forward the Item reworks I now take the
ItemPool in focus: It now does not hold any items
anymore and should be renamed to something like
ItemInfoProvider/ItemHelper, since it's main purpose
is to provide the Defaults for the Item functionality.
There is that SfxItemInfo, only a struct and bundling
SlotID and ItemFlags. There are also the DefaultItems,
just handled as ptrs in an array. It is/was always
error-prone to keep these in sync. Remember that it's
also necessary for the order to not only being sorted
but being increments of one with no gaps allowed in
the WhichIDs to which the Items are bound.
I now bundled that to a new class ItemInfo that joins
WhichID, SlotID, ItemFlags and the default Item. This
is a pure virtual base class, it comes in three
derivations:
(1) ItemInfoStatic:
This is supposed to be global static and hosts the
Item in a std::unique_ptr to ensure cleanup. It is
designed to be constructed once during runtime and
being shared globally. It allows the ItemPtr to be
nullptr to mark as non-static (if initial static is
not possible for some reason) but still offers the
needed data. Most cases (95%+) are of that case.
The contained Item is owned by that instance. The
flag isStaticDefault() is set at the Item.
(2) ItemInfoDynamic:
This is supposed to be used for cases where the Item
cannot be static: Mainly for SfxSetItem (that needs
a Pool itself in the contained SfxItemSet, so lifetime
is bound to that Pool), but other cases showed up in
the transition. These instances live while the Pool
lives and get destructed when the Pool goes down.
Also uses std::unique_ptr for the Item instance for
as much automated cleanup as possible, the contained
Item is owned by that instance, the instance by the
Pool. The flag isDynamicDefault() is set at the Item.
(3) ItemInfoUser:
This is used for UserDefaults that can be set for
every ItemInfo entry to 'overshadow' the default
from the 'outside'. It uses a regular Item and
the central access methods implCreateItemEntry/
implCleanupItemEntry to manage the Item instance,
thus works like a SfxPoolItemHolder. The Item
instance can be globally shared and re-used even
when the Pool goes down. Instances belong to the
Pool and are cleaned up when the Pool goes down.
This Item does not need any further flag to be
set.
The ItemInfos are organized using a class
called ItemInfoPackage:
This bundles groups of ItemInfoStatic to
functional instances. There are derivations/
implementations of this e.g. for Writer ItemPool
bundling all the needed defaults for Writer,
similar for draw/impress, Calc and other usages.
These ItemInfoPackage can be 'registered' at an
ItemPool using it's method registerItemInfoPackage.
This does all the needed stuff to setup that
group of ItemInfos at the Pool (It even sets
internal vars First/LastWhich, that info can just
be derived from the buildup ItemInfo Ptrs).
The ItemInfoPackage has methods 'size()' and
'getItemInfo(index) to allow looping over it
and deliver the infos the Pool needs. The
(forced, pure virtual) overloads of getItemInfo
in the specific implementations check for the
ItemPtr being nullptr and create a exclusive
incarnation of ItemInfoDynamic for the Pool if
needed, returning that. The Pool owns the
ItemInfoDynamic incarnations and uses the
ItemInfoStatic directly. On shutdown it cleans
up the ItemInfoDynamic as needed.
The ItemInfoUser is used by the Pool when a
UserDefault is set/used: for SetUserDefaultItem,
GetUserDefaultItem, ResetUserDefaultItem. It
is not held in a 2nd list, but directly in the
list of ItemInfo'ptrs: To keep track of this
an unordered_map is used that helds the original
ItemInfo associated with the WhichID. That way
no two lookups (as before) are needed to get the
current Pool's default for any WhichID.
The derivations of ItemInfoPackage are
encapsulated and just allow access to an
ItemInfoPackage& with a single method as
return value. All use a static local instance
of a std::array<ItemInfoStatic, FIXED_SIZE>
which constructs all ItemInfoStatic and the
static Item instances - if already possible.
Sometimes it is necessary to overload the
constructor to set some static instances
for Items later than the lib init. These are
also just marked with nullptr as Item instance.
Some need to overload getItemInfo to complete
instances of ItemInfoStatic, if needed, or
create and deliver instances of ItemInfoDynamic.
The registerItemInfoPackage also offers a
optional lambda callback: there were two cases
where local data from the Pool was needed to
incarnate the item - just add that to the
call to registerItemInfoPackage if needed,
see examples in the adapted code.
For the re-use of Items this means that now
in SfxItemSet/SfxPoolItemHolder *true* static
Items can and will be used without RefCount
directly and globally. This is also the case
for dynamic Items, with the exception of
differing Pools for SfxSetItems which cannot
be done.
Future:
That design is already prepared to allow
solving that Pool-chaining problem: currently
there are master/sub-pools and all accesses
have to traverse that structure before even
doing anything.
For the future the idea is more to 'compose'
a Pool by registering ItemInfoPackages, e.g.
for Writer pool you may start with SfxItemPool,
register the writer-specific ItemInfoPackage,
then the one for DrawingLayer (if needed) and
the one for EditEngine.
It should also be possible to get to smaller
granularities of that packages. Ideas for
new ones will emerge. We might also think
about composing Pools which can e.g. run Writer
and Chart, so allowing to use Chart *without*
OLE stuff in Writer - just ideas...
More changes:
- Adapted all stuff, cleaned up old stuff/
definitions
- Removed FreezeIdRanges, that can be done
once per Pool on-demand (and cannot be
forgotten to be called)
- Merged XOutdevItemPool with SdrItemPool
and offered a ItemInfoPackage which joins
both needed sets of Items
- All the cleanup hassle with Pools and
defaults cleaned up
- Adapted all access methods of the pool
to use that new stuff. Pool chaining
currently stays, but I use a central
method 'getTargetPool' instead of
recursive calling to get the correct
Pool for the action
Change-Id: I2b8d3d4c3cc80b1d0d0b3c0f4bd90d7656b4bab7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163157
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Sorted out some methods at ItemPool which process
Defaults to make more clear what is going on and
what which method is doing.
Change-Id: I2568d3e03d0a56a14b6fe4e04521e1a8e22c000b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162643
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove
non-const Sequence::begin()/end() in internal code, 2021-10-15) and
commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Currently a Pool-Attribute (in SfxItemInfo), but should
be a SfxPoolItem property. Originally 'moved' from old
'poolable' used as hint. I identified needs more general
and moved it to where it belongs.
Also reworked SfxItemInfo to no longer have/support
single bollean flags, but a FlagVariable and defined
SFX_ITEMINFOFLAG_* entries to access these, that will
make future changes easier without having to change
all palces where these get defined over and over again.
Added CheckItemInfoFlag for gereral access to that flag
and e.g. NeedsSurrogateSupport to directly check for
the SFX_ITEMINFOFLAG_SUPPORT_SURROGATE flag as syntactical
sugar, that makes the intention clear.
Change-Id: I09c238c7c5b7f721b657d7b0a44dbc8d14e02528
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161982
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Add a disable option for OLE Automation interface that is used
only on Windows.
Change-Id: I86f212977bb604fbae6ac2603bee037b32b5036c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161035
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: I04644c9ca78930d42289368b9a596f44a14b7012
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161746
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ib86f85e6162639d229443cb3026c355c6a659932
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161306
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I6cdb020f19797821c6a70bf01013f6a7718bdcac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161189
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
and
cid#1545605 COPY_INSTEAD_OF_MOVE
cid#1545587 COPY_INSTEAD_OF_MOVE
Change-Id: Iafb1d81dbacfefe70fbddd84b29e827dc137ef07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161077
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546498 COPY_INSTEAD_OF_MOVE
cid#1546384 COPY_INSTEAD_OF_MOVE
cid#1546376 COPY_INSTEAD_OF_MOVE
cid#1546374 COPY_INSTEAD_OF_MOVE
cid#1546373 COPY_INSTEAD_OF_MOVE
cid#1546368 COPY_INSTEAD_OF_MOVE
cid#1546365 COPY_INSTEAD_OF_MOVE
cid#1546356 COPY_INSTEAD_OF_MOVE
cid#1546340 COPY_INSTEAD_OF_MOVE
cid#1546266 COPY_INSTEAD_OF_MOVE
cid#1546236 COPY_INSTEAD_OF_MOVE
cid#1546188 COPY_INSTEAD_OF_MOVE
cid#1546178 COPY_INSTEAD_OF_MOVE
cid#1546166 COPY_INSTEAD_OF_MOVE
cid#1546156 COPY_INSTEAD_OF_MOVE
cid#1546144 COPY_INSTEAD_OF_MOVE
cid#1546143 COPY_INSTEAD_OF_MOVE
cid#1546100 COPY_INSTEAD_OF_MOVE
cid#1546078 COPY_INSTEAD_OF_MOVE
cid#1546041 COPY_INSTEAD_OF_MOVE
cid#1546036 COPY_INSTEAD_OF_MOVE
cid#1546033 COPY_INSTEAD_OF_MOVE
Change-Id: Ib3586d93198992e206baf5c2de5a663d5574aa3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160979
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1545218 COPY_INSTEAD_OF_MOVE
cid#1545232 COPY_INSTEAD_OF_MOVE
cid#1545243 COPY_INSTEAD_OF_MOVE
cid#1545246 COPY_INSTEAD_OF_MOVE
cid#1545251 COPY_INSTEAD_OF_MOVE
cid#1545260 COPY_INSTEAD_OF_MOVE
cid#1545261 COPY_INSTEAD_OF_MOVE
cid#1545276 COPY_INSTEAD_OF_MOVE
cid#1545295 COPY_INSTEAD_OF_MOVE
cid#1545297 COPY_INSTEAD_OF_MOVE
cid#1545301 COPY_INSTEAD_OF_MOVE
cid#1545302 COPY_INSTEAD_OF_MOVE
Change-Id: I97ba935a4a2b8715b55ebbf6e853a66260b2eb90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160686
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I0c70fc1d42031a5a6ebd900cd20b1e7e40d9352d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159703
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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: I76ba8e275033c4d0a3c04964828dc640827cb7cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159073
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Ia4c72f9651b46314241543cd27767e6f1a23a321
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159207
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7a928a2385286f6d1ab3887c8d315af3f47c052d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159135
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic0ec1614d48382bb5735a67bf9588657b9ebd521
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159106
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>
|
|
...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: I30f81bdcd7ba877e65c8f134352669e22d78b033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158192
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I30b2ac77b58e2ae1d1e997a0c830c513542b973d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158101
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Avoids overwriting source location in message
Change-Id: Ia0290c7dd1ab3ea1357712a27ecab75c7b583dd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157893
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...that have been made unused by 7ef3d937415185ef66e32dd3043783eddcd03db5
"loplugin:ostr: Rewrite some uses of O[U]String to use ""_ostr/u""_ustr
literals". (And which means we can remove the relevant code from that plugin
again.)
(This also found a handful of remaining uses that had been hard for the plugin
to discover, along the lines of
> std::map<OUString, int> m = {{u"foo", 0}};
being represented by a
> DeclStmt 0xdaca578 <line:103:5, col:50>
> `-VarDecl 0xdac9150 <col:5, col:49> col:29 s11 'std::map<OUString, int>':'std::map<rtl::OUString, int>' cinit destroyed
> `-ExprWithCleanups 0xdaca548 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>'
> `-CXXConstructExpr 0xdaca508 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>' 'void (initializer_list<value_type>, const std::less<rtl::OUString> &, const allocator_type &)' list std::initializer_list
> |-CXXStdInitializerListExpr 0xdaca480 <col:35, col:49> 'initializer_list<value_type>':'std::initializer_list<std::pair<const rtl::OUString, int>>'
> | `-MaterializeTemporaryExpr 0xdaca468 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' xvalue
> | `-CXXBindTemporaryExpr 0xdaca448 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' (CXXTemporary 0xdaca448)
> | `-InitListExpr 0xdac9df0 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]'
> | `-CXXConstructExpr 0xdaca408 <col:36, col:48> 'const std::pair<const rtl::OUString, int>' 'void (const char16_t (&)[4], int &&) noexcept(_S_nothrow_constructible<const char16_t (&)[4], int>())' list
> | |-StringLiteral 0xdac91b8 <col:38> 'const char16_t[4]' lvalue u"foo"
> | `-MaterializeTemporaryExpr 0xdaca3f0 <col:46> 'int' xvalue
> | `-IntegerLiteral 0xdac91d8 <col:46> 'int' 0
> |-CXXDefaultArgExpr 0xdaca498 <<invalid sloc>> 'const std::less<rtl::OUString>':'const std::less<rtl::OUString>' lvalue
> `-CXXDefaultArgExpr 0xdaca4b8 <<invalid sloc>> 'const allocator_type':'const std::allocator<std::pair<const rtl::OUString, int>>' lvalue
Clang AST.)
Change-Id: I496fe9d4d5e1a033cb7b27b4e04b303f8ddbed4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157756
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I6545cf93b0a101d3a3eea0abe9c1732fcf3dc2d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156850
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The loop was over an array which has only one element, so the
condition should also work directly with its only element.
Change-Id: I5b87cf03d90e9da67ac3ff72b593be0ff5fa322c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129677
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
It's a little easier to read, but mostly it makes an upcoming
loplugin easier to implement
Change-Id: I4ae7db8eda77795dab3255d1afd8ba4f20a8de76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156451
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5746cf045fc7d3191781c2c31631db39ee81bb7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155002
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
|
|
Change-Id: I4e0aa0b167a8e54c1ba85f2b4c86f3f198672553
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154075
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I7866f11e744f4159f1ff5fb5175ee7fe87bbf4a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154515
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When accessibility is enabled, Calc will add tens of thousands of
listeners.
We then spend a significant chunk of time creating SvCTLOptions objects
(attached to ImpEditEngine) and adding and removing those objects from
the related listener lists.
But the required information is already globally cached by the officecfg
module, so we can avoid that overhead and just fetch it directly from
officecfg.
Change-Id: I7ff55fd7c4926866eb7086812275ba8bd6e84c75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152645
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6c87025fc0997b5edbc085fc88333fe9e150eb3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152648
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which flushed out an inconsistency in how SID_NUMBER_TYPE_FORMAT was being used
Change-Id: Ib59ae4c4950136703d18d7485db432a39e3dc39c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152300
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
