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>
...that easily works around the problem that in a rewriter rewriting types of
VarDecls like
T x, y;
it would try to replace T twice. Also, keep the list of removals globally with
the (global) rewriter.
Change-Id: I55b8d11986c2a29e09ff40132fd114a0cc48dc90
...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
Given that locations often point to a (start of) token, even if it's
e.g. getLocEnd(), this should be very useful.
Change-Id: I266e4c0a234262e99158c8f495b631f54f8a5608
Some improvements, like making it simple to actually remove a statement
or a token including its associated whitespace.
Change-Id: I02a5bd919f1fadae1dcd45a76f9d25df353ac518
Clang API doesn't provide this, but it's occasionally needed, and so far
the way has been inspecting the highest possible node in AST and walking down
and remembering, which is complicated, error-prone and annoying.
Change-Id: Id5b72cb5ebfc069e90efe6d673c0ef18ebcdab61
A different way to do 1c0669af2f1f58e6431b5e489ac48a883e242ba7.
Sometimes one piece of code can be represented several times in the AST,
e.g. with default function arguments.
Change-Id: Ic7799fa0bd918a638bdc8ebef69e6aa91d355bdc
This does not always work well, e.g. when building a return value
in a return statement from a temporary, there is CXXConstructExpr
containing CXXTemporaryObjectExpr, which both share the same location.
This reverts commit 1c0669af2f1f58e6431b5e489ac48a883e242ba7.
Turns out removeText( SourceRange ) treats it as a token range, so it's
not always character-exact if used for removal of only several characters
from a token (e.g. an identifier).
Change-Id: I0223d52da90f9535d9ef1d48b0f56d69131536c8
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
