I think I managed to disable this when I converted it to
use the shared plugin infrastructure.
So fix that, and then make it much smarter to avoid various
false positives.
Change-Id: I0a4657cff3b40a00434924bf764d024dbfd7d5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176646
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Qt's qtbase commit [1]
commit cecca90ff23ff27b9396defc21abd472b3fe0003
Author: Thiago Macieira <thiago.macieira@intel.com>
AuthorDate: Tue Oct 1 11:26:30 2024 -0700
Commit: Thiago Macieira <thiago.macieira@intel.com>
CommitDate: Tue Nov 12 17:14:46 2024 -0800
moc: fix support for generating meta objects for nested private classes
introduced a new QT_OBJECT_GADGET_COMMON macro, causing my
`--enable-qt6` clang plugin build with current qtbase git dev
(as of commit 957e2be00a5c45223a5ef842a5f9f2f7b7be882b)
to fail as follows for classes using the Q_OBJECT macro:
In file included from /home/michi/development/git/libreoffice/vcl/qt6/QtAccessibleRegistry.cxx:10:
In file included from /home/michi/development/git/libreoffice/vcl/qt6/../qt5/QtAccessibleRegistry.cxx:11:
In file included from /home/michi/development/git/libreoffice/vcl/inc/qt6/QtXAccessible.hxx:10:
/home/michi/development/git/libreoffice/vcl/inc/qt6/../qt5/QtXAccessible.hxx:27:5: error: declaration nested in DLLPRIVATE declaration redundantly marked as DLLPRIVATE [loplugin:dllprivate]
27 | Q_OBJECT
| ^~~~~~~~
/home/michi/development/git/qt5/qtbase/src/corelib/kernel/qtmetamacros.h:145:5: note: expanded from macro 'Q_OBJECT'
145 | QT_OBJECT_GADGET_COMMON \
| ^~~~~~~~~~~~~~~~~~~~~~~
/home/michi/development/git/qt5/qtbase/src/corelib/kernel/qtmetamacros.h:132:5: note: expanded from macro 'QT_OBJECT_GADGET_COMMON'
132 | Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/michi/development/git/qt5/qtbase/src/corelib/kernel/qtmetamacros.h:98:39: note: expanded from macro 'Q_DECL_HIDDEN_STATIC_METACALL'
98 | #define Q_DECL_HIDDEN_STATIC_METACALL Q_DECL_HIDDEN
| ^
/home/michi/development/git/qt5/qtbase/src/corelib/global/qcompilerdetection.h:190:46: note: expanded from macro 'Q_DECL_HIDDEN'
190 | # define Q_DECL_HIDDEN __attribute__((visibility("hidden")))
| ^
/home/michi/development/git/libreoffice/vcl/inc/qt6/../qt5/QtXAccessible.hxx:25:7: note: parent declaration is here [loplugin:dllprivate]
25 | class QtXAccessible : public QObject
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
26 | {
| ~
27 | Q_OBJECT
| ~~~~~~~~
28 |
29 | public:
| ~~~~~~~
30 | QtXAccessible(css::uno::Reference<css::accessibility::XAccessible> xAccessible);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31 |
32 | /** Reference to the XAccessible.
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
33 | * This is cleared once it has been passed to the QtAccessibleWidget,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
34 | * which then keeps an own reference and takes care of all required
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
35 | * access to the XAccessible for the Qt a11y bridge. */
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
36 | css::uno::Reference<css::accessibility::XAccessible> m_xAccessible;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
37 | };
| ~
1 error generated.
make[1]: *** [/home/michi/development/git/libreoffice/solenv/gbuild/LinkTarget.mk:339: /home/michi/development/git/libreoffice/workdir/CxxObject/vcl/qt6/QtAccessibleRegistry.o] Error 1
Extend the plugin to also take the new macro into account in
addition to Q_OBJECT.
[1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=cecca90ff23ff27b9396defc21abd472b3fe0003
Change-Id: I990f0b25010b3a0f0cc3902f732b93d13bb85d78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176702
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This would have caught the issue discussed in
709b1f3ddb "Make sure VCLXPopupMenu has unique
RTTI". (The commit message talks about RTTI there, while what Clang actually
compared for an optimized implementation of a dynamic_cast to a final class is
vtable pointers, but the overall picture remains the same. Both RTTI and
vtables are emitted along the key function, and if that is missing or inline,
they are emitted for each dynamic library individually, and as internal symbols
on macOS.)
This commit also addresses all the issues found by the improved
loplugin:dyncastvisibility on Linux. See the newly added TODO in
compilerplugins/clang/dyncastvisibility.cxx and
86b86ac87e "Give DocumentEventHolder (aka
EventHolder<DocumentEvent>) a key function" for an issue with key functions for
class template instantiations.
Change-Id: Ia19155efb1d23692c92b9c97ff17f18ae7a1f3ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176576
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...where clang::CXXRecordDecl::forallBases is documented as: "This routine
returns false if the class has non-computable base classes." So, presumably
since
<https://github.com/llvm/llvm-project/commit/bf099f4682bf088aaa49b2c72fb1ef3250213fbb>
"[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)"
changed
> -template <std::size_t I, typename ValueTy>
> -struct tuple_element<I, llvm::StringMapEntry<ValueTy>>
> - : std::conditional<I == 0, llvm::StringRef, ValueTy> {};
> +template <std::size_t Index, typename ValueTy>
> +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>>
> + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {};
in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here
started to trivially always be true for that struct tuple_element
specialization, so the isDerivedFrom check in
CheckFileVisitor::VisitCXXRecordDecl in
compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true
for that struct, so it started to generate
compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra
> InfoVersion:1
> ClassName:tuple_element
> InfoEnd
content, which in turn caused the generated
compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of
> #include "tuple_element.cxx"
and other nonsense, which caused the build to break with
> [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx
> lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found
> 20 | #include "tuple_element.cxx"
> | ^~~~~~~~~~~~~~~~~~~
etc.
(And now spelling out the implementation of forAnyBase here also reveals that
BaseCheckSubclass will never be called with a null BaseDefinition, so the code
handling that has been removed.)
Change-Id: I8a6e42260eae86852ec37a80d058777653fac394
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
which simplifies the hierarhcy.
We never allocate such a thing, we always allocate subclasses, and it
has no real meaning by itself.
Change-Id: Ie6b716c9ea6ca0efe0ae4f39ac345608c45534f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
with clang version 17.0.6 on openSUSE 15.6 we seem to be getting a crash
here (originally reported to me by mmeeks)
Change-Id: I7b0b1b986a7f66af988e58d4fec019b9e29a64da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171754
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I ran into a problem where this global object would be destroyed and
then resurrected during shutdown.
Rather than make the existing code more complex, extend the existing
vcl::DeleteOnDeinit code and re-use that here.
Change-Id: Ib63739f57f489b1131111e9bab1db5fba7fd17bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169697
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
> In file included from libreofficekit/source/gtk/lokdocview.cxx:26:
> In file included from include/vcl/event.hxx:28:
> In file included from include/vcl/outdev.hxx:30:
> In file included from include/vcl/bitmap.hxx:31:
> In file included from include/vcl/region.hxx:26:
> In file included from include/basegfx/polygon/b2dpolypolygon.hxx:27:
> In file included from include/basegfx/range/b2drange.hxx:27:
> In file included from include/basegfx/point/b2dpoint.hxx:27:
> include/basegfx/tuple/Size2D.hxx:30:10: error: this member function can be declared static [loplugin:staticmethods]
> 30 | TYPE getWidth() const { return Tuple2D<TYPE>::getX(); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/basegfx/tuple/Size2D.hxx:32:10: error: this member function can be declared static [loplugin:staticmethods]
> 32 | TYPE getHeight() const { return Tuple2D<TYPE>::getY(); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/basegfx/tuple/Size2D.hxx:34:10: error: this member function can be declared static [loplugin:staticmethods]
> 34 | void setWidth(TYPE const& rWidth) { Tuple2D<TYPE>::setX(rWidth); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/basegfx/tuple/Size2D.hxx:36:10: error: this member function can be declared static [loplugin:staticmethods]
> 36 | void setHeight(TYPE const& rHeight) { Tuple2D<TYPE>::setY(rHeight); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...but no idea why exactly that started to hit me just now
Change-Id: Ibb2b57b54b07461a50375ee64670ff21e4670b8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168082
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(*) remove some debugging code
(*) loosen constraints a little so I can see if there are more
interesting opportunities
(*) rename some local vars to make it read better
(*) strip const/& modifiers from types before comparing
(*) ignore vars/fields that are references, they do indicate that a
class was instantiated
Change-Id: I66014b8f0aa24c2e3ca34af75b75e6cd6c939ea6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167383
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
and adjust the loplugin:stringstatic to cope with OUString that
is also declared in a header as extern, in which case we cannot
mark it as constexpr.
Change-Id: I108aa3ff8cb06a9a6d345cd951883b52dd0318f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167106
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Also the key path was wrong in SlsCacheConfiguration.cxx:
MultiPaneGUI/SlideSorter/PreviewCache
but in Impress.xcs we have
MultiPaneGUI/SlideSorterBar/PreviewCache
hierarchy so this may actually now start to work :)
Change-Id: I4b552be713e6e157edb45692ba78101429aa1c85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166755
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
writerfilter wants to convert incoming RTF and OOXML files into
writer's document model. But it currently has to do so by
manipulating the limited subset that we expose through the UNO
API.
This is both slower and less accurate than having access
to the full document model.
So move it inside, and then we can strip out various hacks, and
optimise imports.
Change-Id: Ie1114d28130ef5f9a786531bc552cb8ee7768015
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165953
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>