Age | Commit message (Collapse) | Author |
|
test drive the new bin/find-unneeded-includes --fwdecl mode
Change-Id: I507fa2b172ec9e348d1d91066ea241f02187b5ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179321
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Id4bf243276f16a7e840df0cacf2ca4151b49ca46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173052
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
When autosize (a frame property) is enabled, then the (text) frame
manages it's height/width based on the content such that all the text
is visible. The user cannot decrease the height/width to be less than
the content height/width, but the resize handles show up, and clicking and
dragging is enabled, which shows a blue virtual resize frame.
This patch adds UI feedback mechanism such that if the drag leads
to some change in any dimention of the original frame, then the
frame color will remain blue, otherwise it turns red.
Change-Id: Id4b3e3ae2c9864154e6028ca03008261bbc3e1b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165817
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: I6d98aab59799365c9a0052f259cd5c8208d995bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164961
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Adds new expert configuration option DragThresholdPixels for
Impress and Draw under Misc/DragThresholdPixels.
Also bumps up the previous hardcoded default
value from 2 to 6.
Assuming this value was set when 640x480 resolution was the
most common resolution, currently scaling the hardcoded
default by 3 makes sense.
(eg. GTK uses 8 pixels as the default)
Change-Id: I35c0eed3ce477685c759f517471ce0bdc8315864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154379
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: I3eb1949c0024ab0241a26c7dec410c774b91cdcb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135793
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8ff465d5755dae7098293702115ab08055814754
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103403
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to
cause failures with clang-cl on Windows now, presumably due to devirtualization:
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals
Replacing certain uses of SVX_DLLPUBLIC with the newly introduced
SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows:
> git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES
to produce a file LINES containing all 640 uses. (Conveniently, all uses
happen to be on different lines.) Manually create a file TOKENS
with 640 corresponding lines, each containing the (class or function) name that
is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then
> nm -D --def instdir/program/libsvxcorelo.so | grep -ivw '[vw]' | c++filt >SVXCORESYMS
> nm -D --def instdir/program/libsvxlo.so | grep -ivw '[vw]' | c++filt >SVXSYMS
> n=$(cat TOKENS | wc -l)
> for ((i=1;i<="$n";++i)); do
> tok=$(head -n "$i" TOKENS | tail -1)
> printf @
> grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore
> printf @
> grep -Fw "$tok" SVXSYMS >/dev/null && printf svx
> printf '@ '
> head -n "$i" LINES | tail -1
> done
to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene
whether it is mentioned in exports from neither (@@@), only from svx (@@svx@),
only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The
numbers that gives is
10 @@@
180 @@svx@
424 @svxcore@@
26 @svxcore@svx@
The 10 @@@ ask for follow-up clean up, but most of them are just left as
SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider
(include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash
(include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of
SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC
would cause "unresolved externals" errors when linking Library_svxcore on
Windows.
The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting.
The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the
chosen name in TOKENS was a too generic function name like Fill, in other cases
it was the name of a class exported from one library but also mentioned in the
arguments of a function exported from the other).
And for sdr::table::SdrTableObj the class itself is defined in svxcore while the
static member functions ExportAsRTF and ImportAsRTF are defined in svx. But
MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static
member functions as SVX_DLLPLUBIC, so move the two functions out of the class.
(There appears to be no real necessity that they were static member functions in
the first place; they don't even need to be friends of the class. Nevertheless,
this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx
may ask for follow-up clean up, one way or another.)
All the output lines that need rewriting (all the @svxcore@@ ones, and the
manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file
CHANGE (containing 451 lines). Then
> sed -E -e 's|^@.*@.*@ ([^:]+):([0-9]+):.*$|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1|' <CHANGE >COMMANDS
> . COMMANDS
to do the changes.
Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Mainly fixing '....' and '..'
Change-Id: Ic928701b319868671b826d757dd94c296fd5e942
Reviewed-on: https://gerrit.libreoffice.org/78668
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
and fix potential leak on early return in SdrDragView::BegDragObj
Change-Id: I707be6e2c7dc2c251f37447fe3cd98c4b50b59d1
Reviewed-on: https://gerrit.libreoffice.org/53751
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
SOSAW080: Make SdrModel& prerequisite to SdrObjects
Added need for SdrModel& in constructors of SdrModel,
SdrPage, SdrView and SdrObjList. Builds, not finished.
SOSAW080: removed and replaced old SdrModel
Removed and replaced GetModel()/SetModel() in all using
classes (SdrObject, SdrPage, SdrView), added accessors
to new referenced SdrModel, adapted all accessing places.
Refactored/Extended ::Clone and ::operator== for these
classes to allow cloning objects to a target SdrModel.
Adapted places where this is done AFAP. Added quite some
comments (tagged with 'TTTT') where possible further work
is needed. Builds completely, thus checking in. This does
not mean that this change is done yet.
SOSAW080: Adapted SdrPage/SdrModel relationship
Also needed to work on copy-construction of SdrPage and hierarchy,
quite some stuff removed, no copy-constructor anymore, no
MigrateItemPool stuff. Builds well, test stuck, will need
some cleanup/finetunung
SOSAW080: Smaller corrections/includes adapted
SOSAW080: Smaller corrections/includes adapted
SOSAW080: Debugging/Stabilizing/MakeUnitTestWork
SOSAW080: Stabilized for UnitTests, cleanups
SOSAW080: Adapted GetObjGraphic to just take a const SdrObject&
SOSAW080: Removed ChangeModel from classes
Classes SvxTextEditSource and SvxDrawPage (including
TextEditSource stuff) do not need change of SdrModel
anymore.
SOSAW080: Adapted some comments to make more readable
SOSAW080: Corrected constructor
SOSAW080: getSdrModelFromUnoModel added override marks
SOSAW080: Added missing includes
SOSAW080: Corrected SdrPage constructor
SOSAW080: Corrected some SdrObject::Clone scenarios
Especially when cloning to another SdrModel and taking
the sdr::properties into account.
SOSAW080: Added include for Mac-Build
SOSAW080: Added Scale to DefaultProperties
If a SdrModel change happens in DefaultProperties copy
constructor (used from Clone()), potentially a Scale
for the SfxItems has to be done.
SOSAW080: Added missing include for MacBuild
SOSAW080: Corrected CppunitTest_sc_anchor_test
An adaption of a SdrPathObj instantiation was missing,
added that. Seems as if that test is no tpart of the
usual 'make' scenario, but used/executed in gerrit builds
SOSAW080: Reworked SvxShape to use SdrObject's SdrModel
SOSAW080: Reworked SvxShape to use SdrObject's SdrModel
SOSAW080: Free SdrObjects when SdrModel goes down
In an UNO API test problem is that SvxShapes reference
SdrShapes, but these are not added to a SdrPage and not
'owned' by the SvxShape. Thus these do not get deleted
at all (same in master, memory leak). I extended
SvxShape::Notify the case for ModelCleared to also
Free the SdrObject when not owner and it's not added to
a SdrPage (in that case it gets deleted with deleting
the SdrModel)
SOSAW080: Solve UNO API calls that move SvxShapes to other Model
Due to UNO API tests I got a call to insert an xShape to a
xDrawPage which was constructed in another Model, this has now to
be done by Cloning the SdrObject to the new SdrModel, getting
rid of the old one and getting all the UNO implementation
stuff right (referemces SdrObject <-> xShape).
1cb7d573d323e98a89761fe662c10c4a654fdec0
24617494a0ef79f6e33dfcb02782a833a81c6434
763f39094b6a48b529a6952d01468f8776c97679
242b9e228a9a042c3a5bdd38b1ea6600144276d5
242b9e228a9a042c3a5bdd38b1ea6600144276d5
33a6f3f306b70c223171aef796dd5ee041ad14df
6878b33f8b05738a44c0910e40a60a0f0d1d58ed
0a636caf3cb36c2f9c6cd11aa22cb9bc435dc8f2
8c4626274a5cc531dad27f27c0c45d4c528fb2fb
446685a49a6d67aedd01cfbbd5e87b07f97a4d7b
c1b5ed3c99bc7219a0061e4ece24ea42afd2889a
22de9a1c8af7c25be5c108671ddc548ba323ed47
4caf6b6fbbe6e8130741d793dffb560fd01d4ed5
488b9601735ec1822433f82f633990063951fe08
c366d60299f239e3df856ddffedb19e743e4be0c
c5137ba8c597c7b5f90318df50e87b93a39a28dc
f9e646242cf89f6fde1315046952252a2c429779
f830fbc5fadd89d04be5edd2a5abf9b0d4bf0410
1694b54903df784385abaa8452e1201e12344238
17bcb44d2e29920c0c74430c2d9c703b36cfa0ad
17bcb44d2e29920c0c74430c2d9c703b36cfa0ad
7b5c241faec7488924e5935ae8b19f785846b5e4
bf097ee7467895823fbd158a2a9543da3b5a5078
Change-Id: Iaf53535de0502a481466be74a1768bbb39f0e78c
Reviewed-on: https://gerrit.libreoffice.org/52526
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
This reverts commit 6c14c27c75a03e2363f2b363ddf0a6f2f46cfa91.
|
|
SOSAW080: Make SdrModel& prerequisite to SdrObjects
Added need for SdrModel& in constructors of SdrModel,
SdrPage, SdrView and SdrObjList. Builds, not finished.
SOSAW080: removed and replaced old SdrModel
Removed and replaced GetModel()/SetModel() in all using
classes (SdrObject, SdrPage, SdrView), added accessors
to new referenced SdrModel, adapted all accessing places.
Refactored/Extended ::Clone and ::operator== for these
classes to allow cloning objects to a target SdrModel.
Adapted places where this is done AFAP. Added quite some
comments (tagged with 'TTTT') where possible further work
is needed. Builds completely, thus checking in. This does
not mean that this change is done yet.
SOSAW080: Adapted SdrPage/SdrModel relationship
Also needed to work on copy-construction of SdrPage and hierarchy,
quite some stuff removed, no copy-constructor anymore, no
MigrateItemPool stuff. Builds well, test stuck, will need
some cleanup/finetunung
SOSAW080: Smaller corrections/includes adapted
SOSAW080: Smaller corrections/includes adapted
SOSAW080: Debugging/Stabilizing/MakeUnitTestWork
SOSAW080: Stabilized for UnitTests, cleanups
SOSAW080: Adapted GetObjGraphic to just take a const SdrObject&
SOSAW080: Removed ChangeModel from classes
Classes SvxTextEditSource and SvxDrawPage (including
TextEditSource stuff) do not need change of SdrModel
anymore.
SOSAW080: Adapted some comments to make more readable
SOSAW080: Corrected constructor
SOSAW080: getSdrModelFromUnoModel added override marks
SOSAW080: Added missing includes
SOSAW080: Corrected SdrPage constructor
SOSAW080: Corrected some SdrObject::Clone scenarios
Especially when cloning to another SdrModel and taking
the sdr::properties into account.
SOSAW080: Added include for Mac-Build
SOSAW080: Added Scale to DefaultProperties
If a SdrModel change happens in DefaultProperties copy
constructor (used from Clone()), potentially a Scale
for the SfxItems has to be done.
SOSAW080: Added missing include for MacBuild
SOSAW080: Corrected CppunitTest_sc_anchor_test
An adaption of a SdrPathObj instantiation was missing,
added that. Seems as if that test is no tpart of the
usual 'make' scenario, but used/executed in gerrit builds
SOSAW080: Reworked SvxShape to use SdrObject's SdrModel
SOSAW080: Reworked SvxShape to use SdrObject's SdrModel
SOSAW080: Free SdrObjects when SdrModel goes down
In an UNO API test problem is that SvxShapes reference
SdrShapes, but these are not added to a SdrPage and not
'owned' by the SvxShape. Thus these do not get deleted
at all (same in master, memory leak). I extended
SvxShape::Notify the case for ModelCleared to also
Free the SdrObject when not owner and it's not added to
a SdrPage (in that case it gets deleted with deleting
the SdrModel)
SOSAW080: Solve UNO API calls that move SvxShapes to other Model
Due to UNO API tests I got a call to insert an xShape to a
xDrawPage which was constructed in another Model, this has now to
be done by Cloning the SdrObject to the new SdrModel, getting
rid of the old one and getting all the UNO implementation
stuff right (referemces SdrObject <-> xShape).
Change-Id: Iaf53535de0502a481466be74a1768bbb39f0e78c
1cb7d573d323e98a89761fe662c10c4a654fdec0
24617494a0ef79f6e33dfcb02782a833a81c6434
763f39094b6a48b529a6952d01468f8776c97679
242b9e228a9a042c3a5bdd38b1ea6600144276d5
242b9e228a9a042c3a5bdd38b1ea6600144276d5
33a6f3f306b70c223171aef796dd5ee041ad14df
6878b33f8b05738a44c0910e40a60a0f0d1d58ed
0a636caf3cb36c2f9c6cd11aa22cb9bc435dc8f2
8c4626274a5cc531dad27f27c0c45d4c528fb2fb
446685a49a6d67aedd01cfbbd5e87b07f97a4d7b
c1b5ed3c99bc7219a0061e4ece24ea42afd2889a
22de9a1c8af7c25be5c108671ddc548ba323ed47
4caf6b6fbbe6e8130741d793dffb560fd01d4ed5
488b9601735ec1822433f82f633990063951fe08
c366d60299f239e3df856ddffedb19e743e4be0c
c5137ba8c597c7b5f90318df50e87b93a39a28dc
f9e646242cf89f6fde1315046952252a2c429779
f830fbc5fadd89d04be5edd2a5abf9b0d4bf0410
1694b54903df784385abaa8452e1201e12344238
17bcb44d2e29920c0c74430c2d9c703b36cfa0ad
17bcb44d2e29920c0c74430c2d9c703b36cfa0ad
7b5c241faec7488924e5935ae8b19f785846b5e4
bf097ee7467895823fbd158a2a9543da3b5a5078
|
|
Change-Id: I1b9a0a01f88e8faf6a8973848598b77dee10a14d
|
|
After 1d852b32d7ad89b2317c04958060f366f8922ca4 these data members
were initialized only in constructor and never changed afterwards,
behaving de-facto as constants.
Convert them to an enum and take the chance to change their type
from sal_uIntPtr to size_t.
Change-Id: Ief33b7d3cfd3e181837f77c5b8a51812e314121d
|
|
Change-Id: Ie9fd55b71a152f428a397d9917918f0e9de39aaf
Reviewed-on: https://gerrit.libreoffice.org/39014
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I032b49f4e1228ef275d7ff8d87ba969dcef687ab
Reviewed-on: https://gerrit.libreoffice.org/37248
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ib8bec97be916d5ea70ae9fb9dc83771b6fec1845
Reviewed-on: https://gerrit.libreoffice.org/35634
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I02e933da66241e99e3b81d90d679f1502bab3fef
Reviewed-on: https://gerrit.libreoffice.org/30866
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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
|
|
The same API is already implemented in sw and sc already, the sd
implementation allows selecting a shape in one view, then creating a
second view, and seeing the selection of the first view in the second
view, without de-selecting and re-selecting the shape in question in the
first view.
Change-Id: Ia36e4772584d132f1ff6a7eb07ca4cadaa384ee9
Reviewed-on: https://gerrit.libreoffice.org/28623
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I2ed581e58523ac8b52aa520f7a02f69f408665fe
Reviewed-on: https://gerrit.libreoffice.org/28587
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ib0a06d94f8b51cce1f29f20d1c00d54be939c076
|
|
Change-Id: I6b7a33b5f1297309a7225cac8150dbf1175506b6
Reviewed-on: https://gerrit.libreoffice.org/26642
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ice72f8d9971e15dd6ef365e64cd567b8581a92d3
Reviewed-on: https://gerrit.libreoffice.org/21797
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86
Reviewed-on: https://gerrit.libreoffice.org/21209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: Icac4ac1a2614e72bc9ff070819533e09eeb1a864
|
|
Change-Id: I71682f28c6a54d33da6b0c971f34d0a705ff04f5
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
'mpModel=pModel' is more readable than 'pMod=pModel1'.
Change-Id: I617d85e2c2d4b6b5b0d235cdd3cd9129e276b28d
|
|
Change-Id: I92158457b3ffaaf7c84c6f4c87708d766c8c9f61
Reviewed-on: https://gerrit.libreoffice.org/17117
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia1b65264fea95077c9dc2fb1288a20c6df0ef84c
|
|
Change-Id: Iac5d80ef4e433c95277237692bda02fa75a24c61
|
|
Change-Id: I1ae00035c5ae9ac620f01982d6e4fff593f7c054
|
|
Change-Id: I2a4c7ef9d33db1c34a4ab338f70f800b30083f4f
|
|
Change-Id: I36e3d7950d64a927ac6f081cf4b163fccd2f4786
Reviewed-on: https://gerrit.libreoffice.org/13549
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
|
|
Change-Id: I78da39fc553b2e5040ee6665377ea51a1c4d04d7
|
|
Change-Id: Ic46fa46c200b94e2e6c5a073ba89b9aae5c14542
|
|
Change-Id: Ia5f104bfd707bcf4e159c78ca2764c861fb0b6d9
|
|
Change-Id: I5335182ea16695c77c2855b34c98220aea2befa1
|
|
Change-Id: I2c280be12f36c1538e922286745aabc62482423d
|
|
Change-Id: I8fdaf2af22dcdd20706d1200bbc1d258e717f414
|
|
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
|