since the latter is rather slow
Change-Id: Ib73cdb923585580777c2265b561c1808e93b2baa
Reviewed-on: https://gerrit.libreoffice.org/33585
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
mostly missing explicit before ctors and
uninitialized member vars
one odd use of std::find
> compilerplugins/clang/implicitboolconversion.cxx
> 800 stlIfFind warning Suspicious condition.
> The result of find() is an iterator, but it is not properly checked.
Change-Id: Iade53494cd7fe8ddb0e110e431449ae5a517fe3b
Reviewed-on: https://gerrit.libreoffice.org/24398
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
I had it locally enabled for like a month now, and it did not produce any more
noise than any of the other plugins, but quite some amount of malformed area
designators had been introduced over time.
Change-Id: I642591496bb9338246ba43a3d988481930c087fb
It's boring and a waste of time to have to keep registering in
include/sal/log-areas.dox new log areas that other people have introduced.
We don't really have a uniform policy for logging anyway, so why bother trying
to enforce a such for the log areas? Anybody uses whatever log areas and log
output style and formatting they want in the code they happen to be working
on. And that's fine with me. We were supposed to be the project that avoids
unnecessary process, rules and bureaucracy, right?
Change-Id: I6bddcb56b58edcd885e5dc743c8730878de0036d
...which can act as either a rewriter or a non-rewriter that emits warnings.
Also added COMPILER_PLUGIN_WARNINGS_ONLY=X to demote warnings from plugin X from
errors to warnings, even under --enable-werror.
Change-Id: I05361936240a890515c6bba2459565417c1746b7
It's possible to get the latter from the former, and the former
is useful for other things too (access to the preprocessor, for example).
Change-Id: I708d709129fd3a35bf7c63da4de09c2e696b382d
If the clang binary comes from a package which had been built before
any of our clang related sources were changed the last time, the timestamp
would be older and so there would be no rebuild. So do the stamp handling
the usual way, clang upgrades will work fine, downgrades will not, but
that's the same problem like with downgrading a library and its headers.
To somewhat mitigate the problem (Clang plugin doesn't get cleaned by
'make clean'), include the full Clang version (which includes SVN revision)
in config_clang.h and make all Clang plugin code include that, so
at least configure re-run will trigger a rebuild if necessary.
Change-Id: I993197f79e92e36105092c92c33b2e1db343e975
Some of the areas are guesses I've added after seeing them, whoever feels reponsible
for whichever part of the code feel free to adjust them.
Change-Id: I2192de84d51cc2bc7c28fa84019d38b465985d15
