...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
add some more false+
which interestingly enough, only started showing up when I switched on
--enable-pch=system
Change-Id: I2d52644dc3665db19b28772eb818c138e063dae4
Each plugin currently uses its own recursive AST run, which adds up.
This patch adds another shared plugin which internally contains all
(suitable) plugins and dispatches to them from the same one recursive
run. This patch converts ~25 plugins and for starmath's accessibility.cxx
reduces clang build time from 5.43s to 5.14s (and it's 4.39s without any
plugins). As there are almost 50 more plugins to go, this can theoretically
result in 4.56s final time, although probably not all plugins can be
that easily converted, if at all.
This mostly requires very little change in many plugins (see e.g.
BadStatics), some even work without any functionality change (e.g.
CharRightShift). Traverse* calls require some changes but are often
not that difficult. WalkUp* probably can't be supported, although some
plugins can(?) possibly be adjusted to not rely on them. And of course
some plugins can be left as they are, using their own recursive run.
See description at the top of generator.cxx for description of how to
convert a plugin.
The sharedvisitor.cxx source is generated based on scanning relevant
plugin sources using a clang-based scanner/generator. The generated
source is intentionally included instead of getting always generated,
as the generating currently takes some time, so it should get updated
in git whenever a change in a plugin triggers a source change in it.
Change-Id: Ia0d2e3a5a464659503dbb4ed6c20b6cc89b4de01
Reviewed-on: https://gerrit.libreoffice.org/68026
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
ScDocument dtor calls ClearLookupCaches(), which calls GetNonThreadedContext().
But ScDocument instances used for copy&paste GetFormatTable() fails
on null mxPoolHelper, because ScDocument ctor doesn't set it in such a case.
So set up the pointer in ScInterpreterContext on demand only if actually
needed.
Change-Id: If3811da5bb00a2d7d404c089ee1bf46037a2cddb
Reviewed-on: https://gerrit.libreoffice.org/68350
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
E.g. ScModelObj::GetFormatter() can be rather deep in the call chain
and it just doesn't make sense to pass ScInterpreterContext* to
all the relevant places (and it's a question if it makes sense
to pass it around at all, googling shows that thread_local is not
really _that_ slow).
Change-Id: I9114ef8a10d82a10968391718099edccde7a2663
Reviewed-on: https://gerrit.libreoffice.org/63184
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
by checking if the current namespace decl is in our code, so we have to
scan less stuff, which results in a 10% perf improvement for me
Change-Id: Idf0e30d57b6d0dcd13daa9ed679c28b9d233d387
Reviewed-on: https://gerrit.libreoffice.org/58942
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This adds vcl::graphic::Manager which is a manager singleton that
tracks all the creation fo graphic objects and swaps them out on
a time and allocation basis.
Time based - every number of seconds it looks for Graphics that
weren't used for a time.
Allocation based - when creating a new Graphic and the total of
Graphic uses more than the total amount of memory for Graphics
defined in configuration, it tries to release the Graphics that
weren't used for a time.
Change-Id: I5dbf74db4a6455d32c4abcbad7be21c7f0534642
Reviewed-on: https://gerrit.libreoffice.org/52396
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
It looks like the main point of these being globals is so that they can
be cleared from various places when tables or table frames are destroyed.
Add a SwDoc parameter to ClearFEShellTabCols() and just iterate
over all shells.
Change-Id: I75ad6b695ee1bfa76b9a05c606b07a3574c70ac4
ImplImageTree was used outside of VCL which is not consistent with
the name and the header also contains a lot of implementation
detail. This separates the implementation to ImplImageTree and
the public interface and singleton to ImageTree only.
Change-Id: I3a26444f0f6971a6b1d83472e9cef19c93192d3e
Reviewed-on: https://gerrit.libreoffice.org/32134
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
To avoid this:
sc/source/core/tool/formulalogger.cxx:55:26: error: bad static variable causes crash on shutdown [loplugin:badstatics]
static FormulaLogger aLogger;
~~~~~~~~~~~~~~~~~~~~~^~~~~~~
sc/inc/formulalogger.hxx:42:31: note: ... due to this member of 'FormulaLogger' [loplugin:badstatics]
const ScFormulaCellGroup* mpLastGroup = nullptr;
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
sc/inc/formulacell.hxx:66:20: note: ... due to this member of 'ScFormulaCellGroup' [loplugin:badstatics]
ScFormulaCell *mpTopCell;
~~~~~~~~~~~~~~~^~~~~~~~~
sc/inc/formulacell.hxx:114:21: note: ... due to this member of 'ScFormulaCell' [loplugin:badstatics]
ScDocument* pDocument;
~~~~~~~~~~~~~~~~^~~~~~~~~
sc/inc/document.hxx:312:27: note: ... due to this member of 'ScDocument' [loplugin:badstatics]
VclPtr<SfxPrinter> pPrinter;
~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
Change-Id: I533e45f655ca928a801188aa48ee818d89a962ac
ScAddInListener has a member
ScAddInDocs* pDocs; // documents where this is used
where ScAddInDocs is set<ScDocument*>, and ScDocument has a memmber
VclPtr<SfxPrinter> pPrinter;
so that's only a chain of (apparently non-owning) pointers.
Change-Id: I050218320eb2c588dcfaee80225f4e45a515ed32
Reviewed-on: https://gerrit.libreoffice.org/29613
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
This is quite similar to SwFrame::GetFrameId(), i.e. it assigns a
numeric identifier to each instance to help debugging, as those
identifiers are stable accross runs.
Change-Id: I9cc57e316435f0284a1d481a956a703be859d67e
Reviewed-on: https://gerrit.libreoffice.org/27669
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...which use std containers and are only found at all with the libc++ container
implementations, not the libstdc++ ones.
Change-Id: Ic9af06139823befad4af1a9a825cba10c115aceb
...about
static ImplImageTree instance;
in ImplImageTree::get (vcl/source/gdi/impimagetree.cxx) due to
StyleIconSet ImplImageTree::maIconSet;
(of type std::unordered_map<OUString, IconSet, OUStringHash>) due to
IconCache ImplImageTree::IconSet::maIconCache;
(of type std::unordered_map<OUString, std::pair<bool, BitmapEx>, OUStringHash>),
reported at least when building against Mac libc++. This is a false positive,
as ImplImageTree::shutDown cleans this up.
Change-Id: Idb1a99aa33f71286e57b31b7adb833e3ee8b5f5a
.... and references. This gives numerous false positives as pointers may
be re-set prior to shutdown, so needs a white-list.
Change-Id: I19a011c6f19501cc31b3d9ae76b599296f132478
Reviewed-on: https://gerrit.libreoffice.org/19949
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
VCL Image/Bitmap/BitmapEx instances must not have static life-time
because then they will be destructed after DeInitVCL() and that
likely segfaults.
Change-Id: I3ff8d32de729c971b190028094cb4efe206395e2