From f2c1cddb9696638f9131e6eb169cb56d3877d84b Mon Sep 17 00:00:00 2001 From: bruntib Date: Fri, 8 Dec 2023 18:35:37 +0100 Subject: [PATCH] [doc] Highlights page for 6.23.0 in GUI --- web/server/vue-cli/src/views/NewFeatures.vue | 327 +++++++++++++++++++ 1 file changed, 327 insertions(+) diff --git a/web/server/vue-cli/src/views/NewFeatures.vue b/web/server/vue-cli/src/views/NewFeatures.vue index 0993720f61..5a67bf21e3 100644 --- a/web/server/vue-cli/src/views/NewFeatures.vue +++ b/web/server/vue-cli/src/views/NewFeatures.vue @@ -2,6 +2,333 @@ + + + + + + +

+ We are happy to announce that CodeChecker added native support for + the GCC Static Analyzer! + This analyzer checks code in the C family of languages, but its + latest release at the time of writing is still best used only on C + code. Despite it being a bit immature for C++, we did some internal + surveys where the GCC Static Analyzer seemed to be promising. +

+ +

+ We expect this analyzer to be slower than clang-tidy, but faster + than the Clang Static Analyzer. You can enable it by adding + --analyzers gcc to your CodeChecker check + or CodeChecker analyze commands. For further + configuration, check out the + GCC Static Analyzer configuration page. +

+ +

+ GNU GCC 13.0.0. (the minimum version we support) can be tricky to + obtain and to make CodeChecker use it, as CodeChecker looks for + the g++ binary, not g++-13. As a + workaround, you can set the environmental variable + CC_ANALYZER_BIN + which will make CodeChecker use the given analyzer path (e.g. + CC_ANALYZER_BIN="gcc:/usr/bin/g++-13"). You can use + CodeChecker analyzers to check whether you have the + correct binary configured. +

+ +

+ You can enable gcc checkers by explicitly mentioning them at the + analyze command e.g. +

+ + CodeChecker analyze -e gcc + +

+ gcc checkers are only added to the exterme profile. After + evaluation, some checkers may be added to other profiles too. +

+ +

+ Under the same breath, we added partial support for the + SARIF + file format (as opposed to using plists) to + report-converter, with greater support planned for + future releases. +

+ + + + + +

+ In previous CodeChecker versions, you could set the review status of + a report using two methods: using + in-source comments, + or setting a + review status rule + in the GUI. The former sets the specific report's review status, + the latter sets all matching reports' review status. +

+ +

+ This release introduces a third way, a review status config file! + One of the motivations behind this is that we wanted to have a way + to set review statuses on reports in specific directories (which + was not possible on the GUI). CodeChecker uses a YAML config file + that can be set during analysis: +

+ + 
+$version: 1
+rules:
+  - filters:
+      filepath: /path/to/project/test/*
+      checker_name: core.DivideZero
+    actions:
+      review_status: intentional
+      reason: Division by zero in test files is automatically intentional.
+
+  - filters:
+      filepath: /path/to/project/important/module/*
+    actions:
+      review_status: confirmed
+      reason: All reports in this module should be investigated.
+
+  - filters:
+      filepath: "*/project/test/*"
+    actions:
+      review_status: suppress
+      reason: If a filter starts with asterix, then it should be quoted due to YAML format.
+
+  - filters:
+      report_hash: b85851b34789e35c6acfa1a4aaf65382
+    actions:
+      review_status: false_positive
+      reason: This report is false positive.
+
+ +

+ This is how you can use this config file for an analysis: +

+ + 
+CodeChecker analyze compile_commands.json --review-status-config review_status.yaml -o reports
+
+ +

+ The config file allows for a great variety of ways to match a + report and set its review status. For further details see + this documentation. +

+ + + + + +

+ + In this release the unknown Checker status has been eliminated. + CodeChecker will enable only those checkers that are either + present in the default profile (see CodeChecker checkers + --profile default) or enabled using the --enable argument + (through another profile or explicitly through a checker name). + +

+ +

+ In previous CodeChecker versions, when you ran an analysis, we + assigned three states to every checker: it's either enabled, + disabled, or neither (unknown). We kept the third state around to + give some leeway for the analyzers to decide which checkers to + enable or disable, usually to manage their checker dependencies. + We now see that this behavior can be (and usually is) confusing, + party because it's hard to tell which checkers were actually + enabled. +

+ +

+ You can list the checkers enabled by default using the CodeChecker + checkers command: +

+ + 
+CodeChecker 6.22.0 output:
+
+CodedeChecker checkers |grep clang-diagnostic-varargs -A7
+clang-diagnostic-varargs
+  Status: unknown
+  Analyzer: clang-tidy
+  Description:
+  Labels:
+    doc_url:/afs/seli.gic.ericsson.se/app/vbuild/RHEL7-x86_64/codechecker/6.22.0/www/docs/analyzer/DiagnosticsReference.html#wvarargs
+    severity:MEDIUM
+
+=>
+CodeChecker 6.23.0 output:
+
+CodeChecker checkers |grep clang-diagnostic-varargs -A7
+clang-diagnostic-varargs
+  Status: disabled
+  Analyzer: clang-tidy
+  Description:
+  Labels:
+    doc_url:/afs/seli.gic.ericsson.se/app/vbuild/RHEL7-x86_64/codechecker/6.23.0-rc2/www/docs/analyzer/DiagnosticsReference.html#wvarargs
+    severity:MEDIUM
+
+ + + + + +

+ Following a thorough survey, we identified numerous areas to + improve on our run/tag comparisons. We landed several patches to + improve the results of diffs both on the CLI and the web GUI + (which should be almost always identical). Despite that this + feature has the appearance of a simple set operation, diff is a + powerful tool that can express a lot of properties on the state of + your codebase, and has a few intricacies. For this reason, we also + greatly improved + our docs + around it. +

+ +

+ A detailed description of the issues are described in this ticket: + #3884 +

+ +

+ One example is that the if the suppression was removed for a + finding, the diff did not show the reappearing result as new (in + local/local diff): +

+ + 
+// Code version 1:
+void c() {
+  int i = 0; // deadstore, this value is never read
+  // codechecker_suppress [all] SUPPRESS ALL
+  i = 5;
+}
+
+
+// Code version 2 (suppression removed):
+
+void c() {
+  int i = 0; // deadstore, this value is never read
+  i = 5;
+}
+
+CodeChecker diff -b version1.c -n version2.c --new
+Did not show the deadstore finding as new.
+
+ + + + + +

+ We landed several patches to improve the readability and usability + of the GUI, with more improvements to come in later releases! The + currently selected event's visual highlight pops a little more now + in the report view, and we no longer show unused columns in the + run view. +

+ +

+ In the report detail page, outstanding and closed issues are + clearly organized into a left tree view. So it will be easier to + see which report needs more attention (fixing or triaging). +

+ + + + + +

+ Especially in the case of clang-tidy, we have observed some + unreasonable number of reports by certain checkers. In some + instances, we saw hundreds of thousands (!) of reports reported by + some individual checkers, and its more than unlikely that anyone + will inspect these reports individually (you probably got the + message about using parantheses around macros after the first 15 + 000 reports). +

+ +

+ We found that these checkers were usually enabled by mistake, and + put unnecessary strain both on the storage of results to the + server, and on the database once stored. Moving forward, + CodeChecker servers will reject stores of runs that have more than + 500 000 reports. This limit is a default value that you can change + or even set to unlimited. Our intent is not to discourage + legitemately huge stores, only those that are whose size is likely + this large by mistake. +

+ +

+ When creating a new product called My product at + endpoint myproduct, you can set the report limit from + the CLI with the following invocation: +

+ + 
+CodeChecker cmd products add -n "My product" --report-limit 1000000 myproduct
+
+ +

+ For an already existing product, you can change the limit by + clicking the pencil at the products page. +

+ + + + + + [analyzer] Promote the missing analyzer warning to an error + #3997 +
    +
  • If analyzers are specified with --analyzers flag and one of them is missing, CodeChecker now emits an error.
    • +
  • Previously, the user could only specify the analyzers without version number e.g.: CodeChecker analyze compile_commands.json -o reports --analyzers clangsa
    • +
  • Now, you can also validate the analyzer's version number e.g.: CodeChecker analyze compile_commands.json -o reports --analyzers clangsa==14.0.0
    • +
  • In both cases, if a wrong analyzer was given, the system exit would trigger.
    • +
+ +

+ --all and --details were deprecated for + CodeChecker analyzers +

+ + + +