Skip to content

v6.0

Compare
Choose a tag to compare
@whisperity whisperity released this 18 Sep 22:21
· 5091 commits to master since this release

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.

❗ Massive backward incompatibility changes ❗

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, 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.