...to find uses of dynamic_cast where the static (base) type has hidden
visibility while the dynamic (derived) one has default visibility, and which may
thus fail at least on macOS like happened in
d5ed3cd6dbd22bb18542778f1c48f4d5b3ae0f95 "Make WinMtfFontStyle's base class
EMFIO_DLLPUBLIC, too".
libcxxabi's __dynamic_cast takes static_type and dst_type arguments. Now, if
dst_type (the derived type, with default visibility) is taken from .so A (and
thus references the version of the base type info hidden in .so A) but the
__dynamic_cast call is made from .so B, it passes for static_type the base type
information hidden in .so B, and __dynamic_cast will consider the cast to fail.
I'm not sure whether hidden intermediary types (in the hierarchy between the
dynamic_cast's base and derived types) acutally cause a problem too, but lets
flag them with the plugin anyway.
The fixes use SAL_DLLPUBLIC_RTTI. For one, there appear to be no other reasons
than type visibility to make those classes SAL_DLLPUBLIC. For another, this
nicely avoids any actual changes on Windows (where SAL_DLLPUBLIC expands to
nothing, and many of the affected classes were explicityl introduced into class
hierarchies as "MSVC hacks").
Change-Id: Ia85a9635cebffb1009a9efc1484b8bd4025585d4
Reviewed-on: https://gerrit.libreoffice.org/41802
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in 0660a30d54eb6762302cf1afd43de01e137f6393 "Avoid loplugin:constparam when
param is subject of cast to non-const pointer"
But turns out this whole avoidance is ill-advised and should eventually be
reverted:
Aug 31 09:09:26 <sberg> noelgrandin, the way you originally handled CastExpr in
constparam's checkIfCanBeConst, your intent was if there's code like
static_cast<T*>(p) and param p is found it can be made const, one would also
need to change that cast to static_cast<T const *>(p) when fixing the loplugin
warning, right?
Aug 31 09:09:43 <noelgrandin> sberg, correct
Aug 31 09:10:10 <sberg> noelgrandin, I messed the up with
0660a30d54eb6762302cf1afd43de01e137f6393
Aug 31 09:10:12 <IZBot> core - Avoid loplugin:constparam when param is subject
of cast to non-const pointer -
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0660a30d54eb6762302cf1afd43de01e137f6393
Aug 31 09:10:24 <noelgrandin> sberg, I probably should have had a test for that
Aug 31 09:10:41 <noelgrandin> tests are better at expressing intent
Aug 31 09:10:56 <sberg> I ran across it in a function that needed to have the
param non-const for API reasons (callback fn), and it looked like the "obvious"
fix there, not needing to add the fn to the blacklist
Aug 31 09:11:26 <sberg> I'll eventually get that fixed again (but want to first
get the Mac and Windows builds to succeed)
Aug 31 09:11:44 <noelgrandin> fair enough
Change-Id: Idef0cfc417ec0597a26a29c8720e3e4051a68e00
...as in WriteCallback (desktop/source/minidump/minidump.cxx), where
void *ptr
is use in
static_cast<char *>(ptr)
Change-Id: I0bd44329029cd793390d0744de3c839612e0b494
ScJumpMatrixToken unconditionally deletes the ScJumpMatrix pointer it
receives. But it's copy constructor also just copies that pointer,
meaning that we could end up freeing that pointer twice.
ScJumpMatrix has no copy constructor, so I just managed it via
shared_ptr.
Change-Id: I9cf13312afb4f2869fdc878e5f34060614e31842
Reviewed-on: https://gerrit.libreoffice.org/41728
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
that can use std::unique_ptr, and apply it in i18npool
Change-Id: Ib410abaf73d5f392c7a7a9a322872b08c948f9e9
Reviewed-on: https://gerrit.libreoffice.org/41438
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
The code in SvXMLExportItemMapper::exportXML was broken as far back as
its introduction in
commit 0c28e3c480a95c03b513c55f029b979bcd9c0401
"Move SvXMLAttrContainerItem to SVX, moved writer only code to sw"
Change-Id: I90043ce8b7263aa56fd0883d350e29b97eeaf99b
Reviewed-on: https://gerrit.libreoffice.org/41282
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Under clang-3.8 we get:
compilerplugins/clang/passparamsbyref.cxx:158:31: error: no member named
'isAssignmentOp' in 'clang::CXXOperatorCallExpr'
Change-Id: Icfba2b624f53f07418674237adc5a47819f73c43
makes writing nice code awkward sometimes.
Also split plugin into two different plugins, the logic was getting
tangled up.
Change-Id: I232e314d29c766c160c29373988dc37a466505be
seems to be annoying some people. I'll run this one myself, and at some
stage create some code for enabling a subset of extra plugins via
configure.ac
Change-Id: Ia95701f63f65751d75b5a3fecffb1fc1a82f38e0
<sberg> noelgrandin, and is loplugin:deadclass even sound?
struct B { B(B const &) {} }; struct D: B { D(): B(*this) {} };
Change-Id: Idadd379b925aa6f9de6c625bffa8560ec4192ac7
<sberg> noelgrandin, 718cdd43c25783d9cd402e381123efe3981cc514 now also
looks through typedef sugar, e.g. complaining about a gdouble -> double
expl. conversion in configmgr/source/dconf.cxx;
I think we want to remain silent about such conversions involving typedefs
<noelgrandin> sberg, ah, good point.
Change-Id: Icbb0d6be273f53e507c91556cf0ccb5a5c03e5a1
Reviewed-on: https://gerrit.libreoffice.org/41175
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
The types 'long' and 'unsigned long' are different sizes on different
platforms, making them wholy unsuitable for portable code.
And when I mean different sizes, I mean 64bit Linux and 64bit Windows
have different bit sizes.
Change-Id: Id4d8cd709bf71a3f85ed6515fae2b0a21ae8c25d
Reviewed-on: https://gerrit.libreoffice.org/41130
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for classes which only have copy/move constructors, and so are
effectively dead
Change-Id: I0b844f301e2200c2b40031856bfdb0b0e2c8f77d
Reviewed-on: https://gerrit.libreoffice.org/41039
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
