| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The forwarding of LinkTarget subclass functions to LinkTarget functions
is currently done in a very elegant way that only requires listing the
bare function names once, but the downside is that the subclass
functions aren't defined in a way that "git grep" or "ctags" can find,
so replace that with more verbose copy-paste definitions.
Change-Id: I4bd7f1b1bc0904ae345958e39403ab508db584a1
Reviewed-on: https://gerrit.libreoffice.org/43196
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 994e38e336beeacbd983faafac480afc94d3947e "loplugin: use TypeCheck instead of
getQualifiedNameAsString" had effectively disabled this plugin (Asserter is a
struct, not a namespace). Fixed that.
* Also improved the checks, for one removing the---expensive---use of
Plugin::parentStmt, for another making the plugin look into (...), !..., and
...&&... expressions.
* However, as the plugin had effectively already been disabled (see above) when
it was switched on generally with 839e53b933322b739a7f534af58c63a2c69af7bd
"compilerplugins: enable loplugin:cppunitassertequals by default", it now hit
way more places than I had initially anticipated. To keep the amount of work
manageable, midway-through I disabled looking into ...&&... expressions for
now. That will be enabled (and resulting warnings fixed) in follow-up
commits.
* Checks like
CPPUNIT_ASSERT(a == b)
that actually want to check a specific overloaded operator == implementation,
rather than using such an operator == to actually check that a and b are
equal, can be rewritten as
CPPUNIT_ASSERT(operator ==(a, b))
to avoid false warnings from this plugin.
Change-Id: If3501020e2d150ad0f2454a65a39081e31470c0f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...as clang-cl doesn't support the /clr switch.
* In configure.ac, capture the MSCV version (that would be used if CC hadn't
been overridden to use clang-cl) into MSVC_CXX.
* The logic which flags to pass into gb_CObject__command_pattern is coded into
the platform-agnostic LinkTarget.mk, so it's too late to try and filter all
relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is
a normal one built with the normal $CXX or a special /clr one built with
$MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures
this information early.
* When building with clang-cl, the generated config_host/config_*.h files
contain values suitable for clang-cl, but not for MSVC. But the .cxx files
compiled with MSVC happen to include config_global.h, and would fail. Hack
around that problem for now by introducing a hard-coded, minimal
solenv/clang-cl/config_global.h that is found first when buliding such a
CxxClrObject. Needs cleaning-up properly.
Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33
Reviewed-on: https://gerrit.libreoffice.org/34509
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
| |
|
|
|
|
|
| |
Change-Id: Ib35d8fcc41e1c49bfef01c980b25c051190cb753
Reviewed-on: https://gerrit.libreoffice.org/32990
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
| |
...instead of leaving it empty. (645583dfd374c8b02f3c0eeba6233a0bb5884d68 "New
compilerplugins/clang unit tests": "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.") In preparation for using compilerplugins/clang with clang-cl on
Windows.
Change-Id: Ica4f16a4b249537f78ce21fcbe7c4afea8214821
|
|
|
...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
|
