We will otherwise miss runner failures for any file that does not
contribute to the diagnostics count.
Note: The tool can also fail during the building stage, but in this case
we will get notified by the signal spy timing out.
Change-Id: Ia9aa797d658b1752e3da6e08a652ee55868955ba
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
The Clang Static Analyzer differs from other analyzers in that it does
not run a binary produced by the build process, but looks at source
files instead. It is therefore completely unrelated to any run
configurations that may or may not exist for the project. This has been
ignored so far, with these two main consequences:
- When running the analyzer, the name of some random run
configuration appears in the application output pane, which makes
it look to the user as if the corresponding executable has been
run, which it has not.
- For projects without run configurations (e.g. libraries),
analyzing does not work out of the box, which makes no sense
conceptually.
So we now create our own run special run configuration (not visible in
the UI) and run it directly via runRunConfiguration() instead of using
the currently active run configuration via runProject().
This fixes both issues listed above.
Change-Id: Icc839816f4a1e6f02a0eb2328c536b44f7304807
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
So users can see how many issues were found before the analyzer has
finished, as well as browse them.
Change-Id: I82452441168ecb370e7b2aac137961ebb5b8bfc3
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
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>
There is no reason why the status of the analyzer run should disappear
after a few seconds.
Change-Id: I16c21f05a03ac31f489312fbe56373a531ecc5d5
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>
...that actually make us use the ProjectInfo with updated
CompilerCallData.
Change-Id: Ieee298b3db64159f3faa02231921275e4466bcb5
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>
