| Age | Commit message (Collapse) | Author |
|---|
|
ItemType is useful and faster than RTTI. Until now it was
implemented by a 16-bit member in the base class, plus
(potentially) all constructors having to hand a value
in at item construction type (of type SfxItemType) to
get that member set correctly.
This works, but there is no reliable way to guarantee
coverage, and there have already been cases with missing
SfxItemType - these fallback to '0' and thus all Items
with ItemType() == 0 are assumed equal and might be
static_cast'ed to the wrong classes. Note that I
identified *35* Items that had no correct ItemType
set/implemented actually. It also uses 16-bit per
incarnated Item at runtime.
I thought and realized now a more systematic approach
to do that with a pure virtual function at the Item
itself. That can also be secured by a clang compiler
plugin in the future to keep it working. It uses one
virtual function per derived class, no longer space
in incarnated Items. Also the constructors will get
more simple again.
But the main aspect is security - we cannot afford
Items potentially being held as equal if they are not.
Unfortunately C++ does not offer something like a
'strict pure virtual function' that would force to
be overloaded in every derivation, but the used
methotology and adding a clang test is reasonably
safe.
Have now done the cleanup of previous method.
Change-Id: I04768285f1e9b73d64b0bb87df401944b5d35678
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180017
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ibdda74f8a779097ab189f77a62adff7a12330bd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177145
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
|
|
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>
|
|
Type info for ScCondFormatItem is now needed, see
<https://ci.libreoffice.org/job/lo_ubsan/2782/console>.
Change-Id: I7cd7762bbd9f961e78d6f2fa98a808ff88a82269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151993
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This implements compact layout for pivot tables. In ooxml each row field
can have a compact layout setting. Support for any such "mixed" layout
of tabular/outline/compact per field is also implemented. This also
implements expand/collpse toggle buttons to field labels to make pivot
tables with compact layout more usable. Such buttons are also available
if other layouts are used.
Conflicts:
sc/qa/unit/pivottable_filters_test.cxx
sc/source/ui/cctrl/checklistmenu.cxx
sc/source/ui/inc/checklistmenu.hxx
Change-Id: Ieaa1f3bd282ebdec804d0b45a0af7b3d95a2027f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151057
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Continuation of https://gerrit.libreoffice.org/c/core/+/88475
Change-Id: Ic41ae7df362a796c56e95b38ccb534bbe045ead7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113497
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
sc, scaddins, sccomp, scripting
Change-Id: Ia99fec9e238033821cb784810edd4762c09bd5db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112049
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ief2538fb61f4519e733ce7592cc7c441b94ac124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88030
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and can then remove some casting
Change-Id: Id821c32ca2cbcdb7f57ef7a5fa1960042e630ffc
Reviewed-on: https://gerrit.libreoffice.org/85022
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ieb1a12f35cf8974c557c6e52eac0cd9fb7f80914
Reviewed-on: https://gerrit.libreoffice.org/84945
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If00a50a36cf2bb5c9b775a4ca1000af5c5be7bf4
Reviewed-on: https://gerrit.libreoffice.org/84892
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ief739616163c68e0e30d6287fdac90c1bcc9d13f
Reviewed-on: https://gerrit.libreoffice.org/84879
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8ed99f19ff6f4751c0867147fc1a60ac917f083b
Reviewed-on: https://gerrit.libreoffice.org/84876
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I628562f1013825e5ba3c0daaf5ee6b098616b6d0
Reviewed-on: https://gerrit.libreoffice.org/84866
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
by inheriting from SdrAngleItem
Change-Id: Ifcaf46b12d685e683984e15ba2264c191c0d1e5f
Reviewed-on: https://gerrit.libreoffice.org/84847
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6a08a86262deae4bed3a05f77d3041a568f23595
Reviewed-on: https://gerrit.libreoffice.org/81853
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This should enable using move semantics where possible e.g. in standard
containers.
According to https://en.cppreference.com/w/cpp/language/move_constructor:
To make strong exception guarantee possible, user-defined move
constructors should not throw exceptions. For example, std::vector
relies on std::move_if_noexcept to choose between move and copy
when the elements need to be relocated.
Change-Id: I6e1e1cdd5cd430b139ffa2fa7031fb0bb625decb
Reviewed-on: https://gerrit.libreoffice.org/77957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
New IWYU and recent developments in f-u-i helped to identify
some non self contained files, those were fixed too.
Change-Id: I3b33b0dee7d7c9afc136510898039cab53990ddf
Reviewed-on: https://gerrit.libreoffice.org/74980
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(1) Migrated all still existing binary load/save stuff
in SfxPoolItem to legacy files. Isolated from Item
implementations. Adapted all usages. No more methods
Create/Store needed, also GetVersion removed
(2) Removed operator= for SfxPoolItem. Adapted all
usages. Goal ist to handle Items more as Objects
('Object-Oriented') in the sense to move/handle
instances, not to copy one instance over another one
(which is more and more problematic with hard to copy
content as UNO API stuff or similar). This lead to
much more usages of std::shared_ptr which correlates
well with future plans fr Items (see dev branch).
Next logic step will be to also remove copy constructor
Linux build and corrections done
Fixed Writer test and removed unused defines
Fixed another unused m,acro
Started to unify the AutoFormat stuff
Changes to OUString constructor usages, tests completely
No idea why, but SfxStringItem constructor which
takes a OUString& now insists of not getting ::OUString's
handed in - changed all 'SfxStringItem.*OUString.*".*"'
accordingly
Change-Id: Ibed7358b18fb019994a7490332b9d797a6694c29
Reviewed-on: https://gerrit.libreoffice.org/71075
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
This takes the loading time from 14s to 13s
Use a o3tl::sorted_vector to reduce searching time
Change-Id: I947a3e5001fe1058cf9bffc9509d026af4122ef4
Reviewed-on: https://gerrit.libreoffice.org/71035
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This takes the loaing time from 1m38 to 15s.
Speed up finding existing pool items in the pool by storing a
sorted_vector, sorted by a compare operator on the item.
memcmp is faster than operator< on std::vector because operator< seems
to be trying to use some kind of lexicographical compare
Change-Id: Id72527106d604adb8cd2d158bb42f89e2b16a85d
Reviewed-on: https://gerrit.libreoffice.org/71009
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
this is the single biggest chunk of stuff my upcoming paramtypedef
loplugin will warn about, so do it separately
Change-Id: I412e69e76406d6d947101885d4cd92c65e021508
Reviewed-on: https://gerrit.libreoffice.org/68486
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
i.e. no way to get any useful information out of it, at least since
commit 8b3fcb6a4f80e803586120535768745f6637b34d
Date: Fri Aug 11 10:01:25 2017 +0530
Removing unused SfxItemPool serialisation from svx
Which means that SID_RANGE_VALUE is also useless.
Possibly the commit that added this had a bug, and it meant to use
SvxDoubleItem, which implements the necessary QueryValue/PutValue
methods to be able to interact with macro code.
Change-Id: I6ffb0c46f6f0864f202d71f0e157d7e1d0f54f51
Reviewed-on: https://gerrit.libreoffice.org/62232
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This mostly affects explicitly defaulted functions that had recently been user-
declared to silence new GCC trunk -Wdeprecated-copy. It is not entirely clear
to me what the best approach is overall, see my mail
<http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20181001/245321.html>
"Re: r343285 - [cxx2a] P0641R2: (Some) type mismatches on defaulted functions
only", but lets just explicitly delete those functions for now.
Change-Id: If8c72f612f67a8feb8b03c2fb988c807e704ef03
Reviewed-on: https://gerrit.libreoffice.org/61259
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...by explicitly defaulting the copy/move functions (and, where needed in turn,
also a default ctor) for classes that have a user-declared dtor that does
nothing other than an implicitly-defined one would do, but needs to be user-
declared because it is virtual and potentially serves as a key function to
emit the vtable, or is non-public, etc.; and by removing explicitly user-
provided functions that do the same as their implicitly-defined counterparts,
but may prevent implicitly declared copy functions from being defined as non-
deleted in the future. (Even if such a user-provided function was declared
non-inline in an include file, the apparently-used implicitly-defined copy
functions are already include, so why bother with non-inline functions.)
Change-Id: I4efe3eb088e5f9096be87dd8240504768755112b
Reviewed-on: https://gerrit.libreoffice.org/58096
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Found with bin/find-unneeded-includes
Simple removal proposals are dealt with here
and a bit of fallout management
Change-Id: Ia6f8d4ca46d7b218f5827052ced5641367bd4478
Reviewed-on: https://gerrit.libreoffice.org/54683
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I1b9193e0d7b320d2b64636eca1bc71041e338d45
Reviewed-on: https://gerrit.libreoffice.org/53900
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I430ee7ff6dc5357593b152f9fe0f73d4b69ccf6a
Reviewed-on: https://gerrit.libreoffice.org/51204
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaaa5b99cdff49bc1e88443ee23d98c005ff84911
|
|
Change-Id: I2efb5c0e5735c179314c6c5de87821cee3b033e1
Reviewed-on: https://gerrit.libreoffice.org/45386
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
the table autoformat stuff does not use these values at all, it just
writes the internal details of PoolItems in a pre-determined order
Change-Id: Id6d8ae7508a8d19f5fd1e70f9a428d324082d3bf
Reviewed-on: https://gerrit.libreoffice.org/45199
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaaf9092ec4d6189492906648b84494d087fed81f
Reviewed-on: https://gerrit.libreoffice.org/41539
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3c8d8ba10de007429b1cdf26f5e8b207f7cc5eea
Reviewed-on: https://gerrit.libreoffice.org/41201
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ib8686d06f8cd477ff4fce948b0ac9c3fe463b129
Reviewed-on: https://gerrit.libreoffice.org/40901
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
which requires explicitly adding null in
1) SdrItemBrowserControl::SetAttributes(const SfxItemSet* pSet, const SfxItemSet* p2ndSet)
where SdrItemBrowserControl is only used by SdrItemBrowser and the only use of that is
within DBG_UTIL in SdrPaintView
2) SwCursorShell::GetContentAtPos( const Point& rPt,
within a #ifdef DBG_UTIL block in
3) SvxSearchDialog::BuildAttrText_Impl( OUString& rStr,
bool bSrchFlag ) const
where the other branch uses SvxResId
4) SfxPoolItem::dumpAsXml(xmlTextWriterPtr pWriter) const
5) XFillStyleItem::dumpAsXml(xmlTextWriterPtr pWriter) const
looks very much like all uses (outside the dumpers) are intended
to be in the ui locale
results in that INetContentTypes::GetPresentation always called with UI Locale
Change-Id: I5a110c107838b4db3c355476426d6532f2b6ce52
Reviewed-on: https://gerrit.libreoffice.org/40538
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
which are exactly the same as the regular SCROW/etc typedefs, and have
been this way since
commit 43a21999a92c99867bc3417291719996776b0647
Author: Oliver Bolte <obo@openoffice.org>
Date: Fri Jun 4 09:00:39 2004 +0000
INTEGRATION: CWS rowlimit (1.1.2); FILE ADDED
Change-Id: Ia7f75d71227ca3167b5fd56019bb9bdf0697d1b0
Reviewed-on: https://gerrit.libreoffice.org/37911
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ia28e35ae5af4f601e9a586a3deffbcd61702b0ca
Reviewed-on: https://gerrit.libreoffice.org/36896
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I5f8b73d7f1c7904c230f43fa4e9c7f62dff89b50
Reviewed-on: https://gerrit.libreoffice.org/36312
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I1996319e5b664dff95f7a9b2346aea6092d333ec
Reviewed-on: https://gerrit.libreoffice.org/36070
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib008613fb06c82791c63d5b074a3e2ff1c3607a0
Reviewed-on: https://gerrit.libreoffice.org/35834
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifbdd7d41f0938e9a03693f88416792ff8087f8c2
Reviewed-on: https://gerrit.libreoffice.org/34850
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and drop the SvxChartTextOrientItem class, unused.
Change-Id: I99100837d1beb953450f57b2cda47d165df1620c
Reviewed-on: https://gerrit.libreoffice.org/34747
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic96fd3b56b2063df0882168a7d02725d3c50515f
Reviewed-on: https://gerrit.libreoffice.org/32961
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1e2a0969ca7e9e0f75079a171150269dfed26507
Reviewed-on: https://gerrit.libreoffice.org/30755
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2f78be8588ed75e1e1e569af01190dad720ff442
Reviewed-on: https://gerrit.libreoffice.org/29258
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
and
coverity#705367 Mixing enum types
coverity#705371 Mixing enum types
coverity#982694 Mixing enum types
coverity#1027717 Mixing enum types
coverity#1371228 Mixing enum types
coverity#1371242 Mixing enum types
coverity#1371280 Mixing enum types
coverity#1371310 Mixing enum types
MapUnit and SfxMapUnit share the same values and
are freely cast from one to the other.
Now that
commit d30a4298bdb5ba53cd1fe659f2b742f218a2e527
Date: Thu Aug 11 15:02:19 2016 +0200
loplugin:unusedenumconstants in package..svtools
removed the SfxMapUnit entries that were directly unused, they
don't match anymore and casting from one to the other is dangerous.
Why there was two of these anyway escapes me, get rid of SfxMapUnit
and just use MapUnit universally
Change-Id: I4db5dcd04b59be2f85b62b728f96c90afe00c57e
Reviewed-on: https://gerrit.libreoffice.org/28234
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
verify that parameters on override methods have the same set of default
values for their params as their parent/super-methods do.
Change-Id: Ibdbc1c6e417fbaa680ea025a6bbf5ba9c2e5bcd2
Reviewed-on: https://gerrit.libreoffice.org/27437
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
