This patch deals with what is likely the most common use case:
Filtering specific messages at a particular location. The current
granularity is essentially per-file (and per-function, where possible),
which seems more useful than taking line numbers into
account, as that would not be robust with regards to code changes elsewhere
in the file. We can fine-tune this if the need arises.
Change-Id: I4e9b2671fa199339cc3b995953d072b840cd3205
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
These test the complete workflow as the user experiences it when
clicking "Start".
Intended usage:
(1) Run sdktool to set up a kit with the toolchain you want
to test against (using a temporary directory).
The tests assume exactly one Kit to be present.
(2) Start Creator with a matching settings path and
"-load ClangStaticAnalyzer -test ClangStaticAnalyzer".
(3) Repeat until all toolchains have been tested.
The initial implementation tests one trivial source file
with both qbs and qmake.
Change-Id: I810f23e2990a789a4dd9f1dd16335fbcf5c5f39f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Otherwise we might try to analyze invalid or vanished files.
Change-Id: I387dfb127618f2db21a538b07e1c152dbd026ca6
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
This plugin adds "Clang Static Analyzer" to the Analyze mode, which
processes all implementation/source project files of the current
project. For this, it will call the clang executable for each file.
The found diagnostics will be displayed in a view similar to the one
used in "Valgrind Memory Analyzer".
The user can specify the clang executable to use and the number of
concurrent processes to launch in Menu: Tools > Options > Analyzer >
Clang Static Analyzer.
Main TODOs:
* Fiddle around the appropriate command line options, currently only
defines and include paths are passed on.
* Tests on Windows / OS X.
* Remove dependency to clangcodemodel by moving the functions that
create command line arguments to CppTools. Mostly they are not even
specific to clang (but would also work with gcc).
* Maybe limit to a range of tested clang versions.
* How to deal with directory containing all the log files after the
user starts a new run or Creator is shut down? (delete it? leave it
there? make it configurable?).
* Find out how to properly integrate the tests.
Imaginable future additions:
* Adding a button to load result/log files from a directory, e.g. if
the user used the 'scan-build' approach.
* Adding a button with a filter menu in order to display only
diagnostics from certain categories, similar to "Valgrind Memory
Analyzer".
Change-Id: I6aeb5dfdbdfa239a06c03dd8759a983df71b77ea
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
