Since Clang doesn't keep backwards binary compatibility, it's necessary
to rebuild when Clang (major version?) changes. This was broken
because e.g. check.cxx didn't include plugin.hxx, and so it didn't depend
on config_clang.h . Now simply force timestamp change if config_clang.h
changes.
This still needs re-running configure though.
Change-Id: Icbc404b37105599f1ca6c8996f5a3d45d50082db
Reviewed-on: https://gerrit.libreoffice.org/72976
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This reverts commit efe2889549.
It is that commit that is broken. The only thing that does not work is
that not all compilerplugin sources depend on config_clang.h, the rest is fine.
So instead of reverting something that in principle works (and even complaining
in the commit message about the original problem), just fix it
(will do in next commit).
Change-Id: Ic7766a97220d5b7ef1cd195320899564140fdf1c
Reviewed-on: https://gerrit.libreoffice.org/72975
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...which causes asserts to fire since <https://github.com/llvm/llvm-project/
commit/04323c24a1ac9464471331d9f6499d3cb95d1ccd> "Added an assertion to constant
evaluation enty points that prohibits …"
Change-Id: Iafbf1cea85d15a38a71275d4cea8303bab500f6a
Reviewed-on: https://gerrit.libreoffice.org/72723
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
...after <https://github.com/llvm/llvm-project/commit/
f19a8b05171a67a290e7d3bd6eba0c95c7b3259c> "Replace ad-hoc tracking of pattern
for an instantiated class-scope" removed
ASTContext::getClassScopeSpecializationPattern. None of the affected plugins
are enabled by default (nor checked by
solenv/CompilerTest_compilerplugins_clang.mk), so just make sure they still
compile, leaving any potentially necessary adaptions to another commit.
Change-Id: I7102851409e78eff284b50337f7ad0f721e1e548
Reviewed-on: https://gerrit.libreoffice.org/71702
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Revert part of
commit dd8d5e5795
Date: Mon Apr 29 11:18:21 2019 +0200
improve loplugin:stringconstant
sberg's original gerrit comment:
but there can also be other problematic overloads for parameters like
`void const *` or `std::string_view`. I'm not sure this change is worth
the potential false positives.
and continuing IRC discussion:
<noelgrandin> I'll revert the compilerplugins/ part
<sberg> noelgrandin, my main concern is that /if/ somebody eventually
runs into such an overload situation, it's really hard to get the
warnings/errors fixed for those people, short of going into the plugin
itself
Change-Id: I4916ce8943c4319d7ef9084e22d6a0eeb430b15c
The declaration in BarChart.cxx is particularly suspicious, because it
was using a < for the KeyEqual template parameter.
Been there since:
commit b2c3233e5f
Date: Thu Dec 21 20:08:33 2017 +0900
chart2: suspend/resume setting rects dirty for 3D shapes
comphelper::OInterfaceCompare is no longer necessary
Change-Id: I8278c4a3d9113a18570ca237cd05d553ec8f3975
Reviewed-on: https://gerrit.libreoffice.org/71537
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Inherit from tools::WeakBase non-virtually, so that we can use a
static_cast in tools::WeakReference::get instead of a dynamic_cast.
This takes the file-open time from 1m21 to 40s for me.
Add a clang plugin to make sure we don't accidentally end up inheriting
from tools::WeakBase more than once.
Change-Id: I9c7c36403333f99094e1f9d8cce2ecd9200377f9
Reviewed-on: https://gerrit.libreoffice.org/71231
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
if we're doing a find/insert on a set or a map, it is better to just do
a conditional insert/emplace operation than triggering two lookups.
Change-Id: I80da5097f5a89fe30fa348ce5b6e747c34287a8d
Reviewed-on: https://gerrit.libreoffice.org/70937
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to find more bugs like the one addressed in
6340daac7b "Revert broken
loplugin:sequentialassign change". What it does is: "Warn when a variable is
referenced from its own initializer. This is not invalid in general (see C++17
[basic.life]), but is at least suspicious." It found one false positive
(addressed with 884ad0d1af "Split
localProcessFactory function into class with setter and getter") and five true
positives (addressed with e0ccbe72ed "Fix use of
variable before its lifetime begins" and
0e335af4d3 "Fix uses of variables before their
lifetimes begin").
Change-Id: I4c45cceaa042e93b37ad24a54784c027f6ca1f87
Reviewed-on: https://gerrit.libreoffice.org/70897
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Look for places we are assigning to the same variable twice
in succession, which means we can simplify that to a single assign
Change-Id: I499d20e28f5595e81e927bef8e1bf364eea8ba91
Reviewed-on: https://gerrit.libreoffice.org/70531
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...as seen by clang-cl when there are function parameters of function pointer
type involving SAL_CALL
Change-Id: Ie35f00d4e15ca777b14dd5968cdbd97e43bca1a1
Reviewed-on: https://gerrit.libreoffice.org/69789
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for places we are doing code like:
Reference<XProperty>(model, css::uno::UNO_QUERY)->getAsProperty()
which might result in a SIGSEGV is the query fails
Change-Id: I5cbdbc9e64bd0bed588297c512bf60cbacb9442e
Reviewed-on: https://gerrit.libreoffice.org/69044
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In my macOS build, that clang::tooling::runToolOnCodeWithArgs invocation failed
to find headers like cassert and assert.h, which works now with
COMPILER_PLUGINS_TOOLING_ARGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -isystem /Users/stephan/Software/llvm/inst/include/c++/v1
added to my autogen.input (I build against my Clang trunk libc++ whose headers
are at /Users/stephan/Software/llvm/inst/include/c++/v1).
Change-Id: Idbffa39c9fd4a88743fd498b8f7b6c9c56d7630d
Reviewed-on: https://gerrit.libreoffice.org/69538
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I'm not seeing as much as I would expect here, mostly because pahole
seems to be having trouble parsing quite a few of our structures, and
consequently producing useless data than I then ignore.
XDash 24bytes -> 20bytes
vcl::font::FeatureDefinition 64bytes -> 56bytes
SvXMLTokenMapEntry 16bytes -> 12bytes
SvXMLItemMapEntry 16bytes -> 12bytes
SwContentAtPos 40bytes -> 32bytes
Change-Id: I74c8b93f74b8352f48ef552d7d4239aa7f4237d4
Reviewed-on: https://gerrit.libreoffice.org/69304
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
