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
As per sberg' suggestion
Limit it to == and !=, because some people like the flow of inequalities
like: "0 < a && a < 42"
The changes to sal/ were made using the rewriter.
The rewriter still has one bug, in pipe.cxx, it managed to pick up
some random piece of macro. No idea why.
Change-Id: I01305f9c5396a4b6c7421d6e92f1b4b529388e82
Reviewed-on: https://gerrit.libreoffice.org/30962
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to catch new places where defined'ness of OSL_BIG/LITENDIAN would be checked
without osl/endian.h being included; cf.
e2f08f9def0869460ad38a1c2adb450778290f6e "connectivity, sc: add missing #include
<osl/endian.h>" and 2b14fb3a4f92b928f0a5fc536c6a5f4a6e51a9b8 "cppcanvas, oox:
add missing #include <osl/endian.h>".
Change-Id: I167c8916a01391b7dacad7325153ccf35d3ba9dc
(like in vcl/inc/osx/a11ywrapper.h's AquaA11yWrapper), at least on recent Clang
trunk, from within the call to cast() in
cast<RecordDecl>(getDeclContext())
as the decl context apparently is something other than a RecordDecl.
Change-Id: I238bae44d6db0f04bf8f90b0032489e3b4822eee
...other options to avoid such irrelevant warnings can be to move code to an
include file and/or to define a dummy main() accessing otherwise unreferenced
entities.
Change-Id: Ifd44e376b35ef68496f3aba6a3c046d684824000
look for final classes, and make sure they don't have protected members
Change-Id: I1fa810659bba02b61a5160dbfd8e24185ec9abf4
Reviewed-on: https://gerrit.libreoffice.org/30895
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to check that loplugin produces warnings/errors as expected:
* Clang has a -verify switch that makes it easy to write test input .cxx files
that list in comments all the warnings/errors that are expected, and let Clang
check those expectations instead of generating object code. See
include/clang/Frontend/VerifyDiagnosticConsumer.h in the Clang source tree for
documentation.
* Introduce a CompilerTest gbuild class that uses the existing LinkTarget class
as much as possible. Checking the input files is implicitly phony, as the
compilation step doesn't generate any object files, and the link step does
nothing because there is no gb_LinkTarget_set_targettype for CompilerTest.
The setup at least works for Clang on Linux (will need adaptions for Clang on
Windows; compilers other than Clang are not relevant for now given this is
used to check compilerplugins).
* Definition of gb_CFLAGS_WERROR in solenv/gbuild/platform/com_GCC_defs.mk needs
to be lazy ('=' vs. ':=') so that CompilerTest can override it: The Clang
-verify mode wants the input files to specify whether the loplugin diagnostics
are warnings or errros, so they consistently need to be errors independent of
--enable-werror configuration.
* A first (example) test is in compilerplugins/clang/test/salbool.cxx. The
corresponding gbuild CompilerTest instance is in
solenv/CompilerTest_compilerplugins_clang.mk for now. The reason for that odd
split across compilerplugins/ and solenv/ is that there is no
compilerplugins/Modules_compilerplugins.mk file, so this setup is the easiest
hack for now (to be cleaned up). (Another area that could be improved is that
all test files need to be listed explicitly in the CompilerTest_*.mk file,
instead of, say, using all .c/.cxx/.m/.mm files in a specified directory.)
* The test is run somewhat late during a top-level 'make', after loplugin has
already been used in compilation. But it can be run manually (e.g., 'make
solenv') when making changes to loplugin during development.
Change-Id: I01e12fb84887d264ac03ef2484807458c2075af4
Look for places where we are accidentally assigning a returned-by-value
VclPtr<T> to a T*, which generally ends up in a use-after-free.
Change-Id: I4f361eaca88820cdb7aa3b8340212db61580fdd9
Reviewed-on: https://gerrit.libreoffice.org/30749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Most of its virtual member functions are (though insertRow is already a curious
exception), even though they are defined, so smells like a copy/paste error
rather than deliberate design. And appears to have been the only reason why
loplugin:unnecessaryoverride filtered out such overriding of pure base
functions.
Change-Id: Ib2a40af9cd3cd3dbb26c4147f7d01de4e11f5f6e
This is what it is actually is, we dropped support for server-side fonts
for a long time now. Renamed also a few related classes, but left
ServerFontLayout* ones as they will go away soonish.
Change-Id: I68a6dad51b6972368b7bf85a0b9c8089cc12740e
Reviewed-on: https://gerrit.libreoffice.org/30390
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
Tested-by: Khaled Hosny <khaledhosny@eglug.org>
which can be replaced with using declarations.
Is there a more efficient way to code the search? Seems to slow the
build down a little.
Change-Id: I08cda21fa70dce6572e1acc71bf5e6df36bb951f
Reviewed-on: https://gerrit.libreoffice.org/30157
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
where using a std::map instead of a std::set meant that it
sometimes miscounted the number of callsites
Change-Id: I1e2ebcf44fe006827e66620ae4c9bbc813835414
...that got in, for no apparent reason, when various, slightly different
implementations of isInUnoIncludeFile got consolidated into one.
Change-Id: I64a9eb62703d57a0b7b57720ec9f251ffa780691
