| Age | Commit message (Collapse) | Author |
|---|
|
(*) create a rewriting plugin to do most of the work, heavily
based on the fakebool plugin
(*) but there are still a number of "long"s in the codebase
that will need to be done by hand
(*) the plugin needs lots of handholding, due to needing to
add #include and update macros
Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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: If55e51b8627083ba3ece2b3270adb47668b25e9d
Reviewed-on: https://gerrit.libreoffice.org/81705
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I778ae09c4b0fd3e18a37db4aa3f2affda2c8e86c
Reviewed-on: https://gerrit.libreoffice.org/41053
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>
|
|
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
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>
|
|
tools/rtti.hxx removed
completed the interface of some Sdr.* Items
and removed pseudo items
Change-Id: I0cdcd01494be35b97a27d5985aa908affa96048a
Reviewed-on: https://gerrit.libreoffice.org/19837
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
|
|
Change-Id: I71682f28c6a54d33da6b0c971f34d0a705ff04f5
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Change-Id: I8ee3c1cf551f5b242d20cf244d728b79e68616ed
Reviewed-on: https://gerrit.libreoffice.org/11637
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
since all two of the actual call-sites only care about whether
it is a valid presentation or not, not what kind of presentation it is.
Change-Id: I75717c88878d37b2897741b0c833ff283b3fee59
|
|
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
|
|
...where the latter contains SAL_OVERRIDE annotations
Change-Id: Id64794b388d83dfe7026440e8b20a5b5efd412d1
|
|
Change-Id: I5335182ea16695c77c2855b34c98220aea2befa1
|
|
Change-Id: I2c280be12f36c1538e922286745aabc62482423d
|
|
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
|
