**CodeChecker 6.0** brings a huge amount of improvements to the CodeChecker infrastructure. This new major release sets forth a new direction aimed to increase the usability and effectiveness of CodeChecker as a code analysis and defect triaging system.
:exclamation: Massive backward incompatibility changes :exclamation:
This new **major** release changed the infrastructure in a way that your current CodeChecker usage might no longer be applicable.
* Due to internal database layout changes, any CodeChecker database that was created with versions of CodeChecker `5` **is not usable**. You'll need to reanalyze your project.
* The invocation of CodeChecker scripts have changed. Please make sure your custom integration scripts (if such exist) are working before relying on them. There is a high chance they **won't**.
* The API to access the server programmatically has also changed. Custom clients, such as the [Eclipse plugin](http://github.com/Ericsson/CodeCheckerEclipsePlugin/), may no longer work properly.
Most important backward incompatible command line changes
* CodeChecker `store` and `cmd` subcommands now take `--url` instead of `--host`, `--port` as per the product system, to specify on which server and in which product the commands should be executed on. For example instead of `CodeChecker store --host localhost --port 8555 -n run_name` you should use `CodeChecker store --url localhost:8555/Default`
* The `check` command which wrapped over `log`-`analyze`-`store` has been dropped. `quickcheck` has been renamed to `check`. An extra argument, `--quiet` has been introduced to `analyze` which silences analyzer output from the standard output. (882)
Analysis framework
Major improvements
* `analyze` now supports **incremental analysis**, in which the subsequent analyses of the project updates the contents of the `OUTPUT_DIR` folder, without duplicating `plist` files, or requiring the user to do a full analysis. (719)
* `--add-compiler-defaults` option detects compilation target and `gcc` include directories, thus cross-compilation can be auto-detected. If `--saargs` or `--tidyargs` were used for the analyze sub-command to specify (cross) compilation target or include directories, they can now be replaced by a simple `--add-compiler-defaults` switch, which will auto-detect these compiler settings. (921)
Minor changes
* Various crashes and infinite hangs arising from analysis failure handling and dependency generation have been fixed. (790)
* `CodeChecker analyze` now takes an optional `--capture-analysis-output` argument which makes successful analyzer invocations' output to be saved into the `OUTPUT_DIR`. (802)
* Skip-files not applying to headers have been fixed. (860)
* The `checkers` sub-command has been unified to the new structure, so `CodeChecker checkers` now does the same as `codechecker-checkers` did since version 5.8. (856)
Discontinued features
* The `check` command which wrapped over `log`-`analyze`-`store` has been dropped. `quickcheck` has been renamed to `check`. An extra argument, `--quiet` has been introduced to `analyze` which silences analyzer output from the standard output. (882)
Report storage
Major improvements
* With the changes introduced in incremental analysis, CodeChecker now stores the **detection status** of a bug report. This feature requires the user to always analyze into the same OUTPUT_DIR and then store the results from this folder. A bug can be _new_, _unresolved_, _resolved_ or _reopened_. (724)
* Each bug begins its life as _new_. When a subsequent `store` call finds this bug again, the status will change to _unresolved_, and will stay there, until the bug disappears from the analyzer output. In this moment, the status will be _resolved_. If a _resolved_ bug ever appears again in the analyzer results, its status will change to _reopened_. A _reopened_ bug can turn _resolved_ or _unresolved_ in the next check depending on its status.
* Storing analysis results have been made much faster by introducing a simpler transmission approach. (724)
* The **multiple product system** gives the users the ability to attach multiple analysis result databases to the same running `CodeChecker server` instance. These are separate databases each containing analysis results, managed in a new "configuration database", which is specified in the server's command-line. (773)
* Subsequent `store` calls with the same _run name_ can now be tagged, e.g. to point out which version of the project was used. (885)
Minor changes
* `CodeChecker` subcommands now take `--url` instead of `--host`, `--port` as per the product system, to specify on which server and in which product the results should be stored to. (773)
Web viewer application
Major improvements
* **CodeChecker now has a logo!** (771)
* Bug reports can now be **commented**. Comments are shown for the same report found in multiple runs. (742)
* Bugs can now be assigned a **review status** of _Unreviewed_, _Confirmed bug_, _False positive_, _Won't fix_, along with an optional comment on why this status was applied. (768)
* This replaces the _suppress_ feature of the web application. Source code suppressions are imported into this new system as _False positive_ reports.
* A new **filtering system** has been created which makes the Web viewer much more versatile at searching for reports. (847)
* The history of run updates are stored and it is possible to recall the results of an earlier run (run history). It is also possible to "version tag" each update from command line and search for active reports based on update date. (781)
* Report Uniqueing: The same bug can be found by the analyzer on multiple paths and in multiple runs. A semantically unique bug is identified with a bug identifier hash. In the web viewer it is possible to list only semantically unique bug reports. (811)
* Checkers Summary Table: Provides a summary statistics of reports found by checkers summarized for all runs. (826)
* The web viewer has been updated with a new homepage that gives the users ability to search and select the product they want to view. (773)
* A new **user guide** for the web application has been added. (865)
* Reports that refer to semantically the same bug are now grouped on the viewer. (891)
Minor changes
* Tool-tip showing the full message in the bug path list is placed to start accordingly to the path list, not at the left center of the browser. (720)
* The list of runs can now be filtered for substrings in the run's name. (753)
* The username of the logged in user is now shown in the viewer. (754)
* Diffing two runs can now be made with radio buttons explicitly showing what will be diffed against which other run, instead of having to tick two check boxes in an order. (766)
* The bug steps are now also shown in the left-hand view, not just in the code. Floating bug step bubbles in the code were given better highlighting. (798)
* The code viewer has been made significantly faster. (815, 871)
Command-line viewer client
Major improvements
* The `CodeChecker cmd sum` sub-command now prints a more detailed breakdown on what reports are found per a particular checker. (870)
* The command-line viewer also takes some new arguments for the new **filtering system**. (918)
Minor changes
* Due to the removal of the _suppress_ feature, `CodeChecker cmd suppress` now can only be used to import suppression data into a server. (768)
* `CodeChecker cmd` subcommands now take `--url` instead of `--host`, `--port` as per the product system, to specify on which server and in which product the commands should be executed on. (773, 873)
* Most of the command-line tools now take run names as a positional argument instead of `--name`. (856)
* Local compare mode will now properly understand suppressions in the souce code on the local side. (858)
Security
Major improvements
* CodeChecker Web server can be accessed through secure (encrypted, authenticated) `HTTPS`. (899)
* CodeChecker now supports a way to isolate user access and define **permissions** between the products configured. (857)
Miscellaneous improvements
* The bug report storage database has been revised, the new version of the database stores considerably less data from analyses, and we improved response time by making the database faster. (709, 756, 764)
* The documentation has been heavily extended to help our users better.