CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy
APACHE-2.0 License
Full Changelog: https://github.com/Ericsson/codechecker/compare/v6.23.0...v6.23.1
Published by cservakt 11 months ago
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:https://clang.llvm.org/docs/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:https://clang.llvm.org/docs/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: https://github.com/Ericsson/codechecker/issues/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 this image, you can see how much the selected event "pops" after this release, and also, how other events' opacity was a lowered a bit, which allows arrows to be seen through them.
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:
--analyzers
flag and one of them is missing, CodeChecker now emits an error.CodeChecker analyze compile_commands.json -o reports --analyzers clangsa
CodeChecker analyze compile_commands.json -o reports --analyzers clangsa==14.0.0
--all
and --details
were deprecated for CodeChecker analyzers
With the introduction of the GCC Static Analyzer, we think that the --all
flag was more confusing than useful -- its a reasonable assumption that any system will have a version of GCC available. The default behaviour prior to this release was to only list analyzers that were available for analysis: the binary was found, met the version criteria, and was functional. The --all
flag listed all supported analyzers, even if they were not available. We changed the default behaviour to always list all supported checkers, and --all
is ignored. We emit helpful warnings for analyzers that CodeChecker supports, but can't analyze with.
--details
could be used to print additional version information of the binary, but we didn't feel like it provided any value above what the non-detailed query gave, and it was impossible to pretty print. After this release, this flag will also be ignored.
ldlogger.so
path https://github.com/Ericsson/codechecker/pull/3976
Full Changelog: https://github.com/Ericsson/codechecker/compare/v6.22.2...v6.23.0
Published by vodorok 11 months ago
Fixed the SARIF file location according to the GCC documentation.
Changed GCC's output format to sarif-stderr.
Temporarily ignored compiler warnings in GCC.
Replaced the multiprocessing library with multiprocess. This resolved issues in multiprocess library usage on different platforms but mostly on OSX. Added in https://github.com/Ericsson/codechecker/pull/4076
Fixing a crash when CC_ANALYZERS_FROM_PATH env variable is set in https://github.com/Ericsson/codechecker/pull/4084
Corrected a bug about the --enable-all flag not disabling specific warnings.
Fixed non-determinism in the appearance of clang-tidy checkers.
Prevented duplicate addition of extra arguments in cppcheck.
Resolved an issue with the AnalyzerContext lazy initialization.
An error was fixed when loading the report in the report view that caused the review status dropdown menu's value to fail to update when switching to a report with a different status. Fixed in in https://github.com/Ericsson/codechecker/pull/4082
The issue with building ReadTheDocs has been rectified. You can view the latest docs here: https://codechecker.readthedocs.io/en/latest/
In addition, we have implemented modifications to the PyPI action in order for a more reliable package publishing
Full Changelog: https://github.com/Ericsson/codechecker/compare/v6.23.0-rc1...v6.23.0-rc2
Published by bruntib 12 months ago
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:
# review_status.yaml
- filepath_filter: /path/to/project/test/*
checker_filter: core.DivideZero
message: Division by zero in test files is automatically intentional.
review_status: intentional
- filepath_filter: /path/to/project/important/module/*
message: All reports in this module should be investigated.
review_status: confirmed
- filepath_filter: "*/project/test/*"
message: If a filter starts with asterix, then it should be quoted due to YAML format.
review_status: suppress
- report_hash_filter: b85851b34789e35c6acfa1a4aaf65382
message: This report is false positive.
review_status: 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 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.
In this release the unknown status has been eliminated, and we deal with dependencies using other means. Moving on, 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.
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.
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 this image, you can see how much the selected event "pops" after this release, and also, how other events' opacity was a lowered a bit, which allows arrows to be seen through them.
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:
clang-diagnostic-<warning-name>
(instead of W<warning-name>
)After analysis, reports from clang compiler warnings (well before this release) were attributed to clang-diagnostic-<warning-name>
instead of -W<warning-name>
that is usually given to the compiler to enable <warning-name>
. We did this so that warnings from different compilers could be differentiated. However, you could only enable <warning-name>
as a checker by referencing it as W<warning-name>
. In this release, we fixed this inconsistency.
Moving forward, you can enable a clang warning with the following syntax:
CodeChecker analyzer -e clang-diagnostic-deprecated-copy
instead of
CodeChecker analyze -e Wdeprecated-copy
which is no longer supported. You can list all clang-diagnostics with the CodeChecker checkers
command.
--all
and --details
were deprecated for CodeChecker analyzers
With the introduction of the GCC Static Analyzer, we think that the --all
flag was more confusing than useful -- its a reasonable assumption that any system will have a version of GCC available. The default behaviour prior to this release was to only list analyzers that were available for analysis: the binary was found, met the version criteria, and was functional. The --all
flag listed all supported analyzers, even if they were not available. We changed the default behaviour to always list all supported checkers, and --all
is ignored. We emit helpful warnings for analyzers that CodeChecker supports, but can't analyze with.
--details
could be used to print additional version information of the binary, but we didn't feel like it provided any value above what the non-detailed query gave, and it was impossible to pretty print. After this release, this flag will also be ignored.
ldlogger.so
path https://github.com/Ericsson/codechecker/pull/3976
Full Changelog: https://github.com/Ericsson/codechecker/compare/v6.22.2...v6.23.0-rc1
Published by bruntib over 1 year ago
CodeChecker failed to build on Ubuntu 22.04 in its previous release because of two issues: some of our dependencies broke with the release of python3.9, and we didn't support GNU Make-s new way of creating build jobs. These issues are all fixed now, so CodeChecker should work with the latest version of python and GNU Make!
-fno-lifetime-dse
#3913, -Wno-error
, -fprofile
#3937, #3941)
report-converter
crashed when SourceLine
has no source_path
attribute) #3917linux_spawn
alongside exec*
calls in the logger #3930logger.so
in LD_PRELOAD
#3919
LD_PRELOAD
environment variable where ldlogger.so
was set with a relative path. Due to the relative path LD_LIBRARY_PATH
has to be set too. However, this latter environment variable is overridden by the build systems many times. So CodeChecker uses an absolute path in LD_PRELOAD
and eliminates the usage of LD_LIBRARY_PATH
.lxml
to 4.9.2
#3896Full Changelog: https://github.com/Ericsson/codechecker/compare/v6.22.0...v6.22.2
Published by vodorok over 1 year ago
[fix][server] Fix webapp crash when using component filter
CodeChecker webapp was crashing when using the component filter, which has been fixed in this release. #3887
[doc] Make every second release highlight green #3882
Published by bruntib over 1 year ago
After another round of optimizations, CodeChecker store
is ~2 times faster than in v6.21.0. Combined with the previous release, storing may be as much as 4 times faster than v6.20.0., with larger result directories seeing a greater degree of improvement.
This should allow those that use CodeChecker in CI loops to see fewer timeouts due to long storages, or lower timeout tresholds significantly.
CodeChecker now supports an analysis mode where for each source file, it tries to find the closest compile_commands.json file up in the directory hierarchy starting from the source file.
If your project is structured such that multiple folders act as their own root folder (hence the name multiroot), CodeChecker should be able to support that out of the box. clangd and clang-tidy already works this way:Β https://clangd.llvm.org/installation.html#compile_commandsjson
This feature also affects the CodeChecker Visual Studio Code plugin, where analysis will be done on multiroot projects as well Ericsson/CodecheckerVSCodePlugin#113.
Previously the input of analysis must have been a compilation database JSON file. This PR supports the following new CodeChecker analyze
invocations, as long as a corresponding compilation database file is found:
# Analyze a single file.
CodeChecker analyze analyze.cpp -o reports
# Analyze all source files under a directory.
CodeChecker analyze my_project -o reports
CodeChecker is now able to parse additional fields from plist files especially relevant to dynamic analyses.
https://github.com/Ericsson/codechecker/blob/master/docs/analyzer/user_guide.md#dynamic-analysis-results
<dict>
<key>diagnostics</key>
<array>
<dict>
<key>category</key>
<string>unknown</string>
<key>check_name</key>
<string>UndefinedBehaviorSanitizer</string>
<key>report-annotation</key>
<dict>
<key>testcase</key>
<string>yhegalkoei</string>
<key>timestamp</key>
<string>1970-04-26T17:27:55</string>
</dict>
<key>path</key>
<array>
...
</array>
</dict>
Unlike for static analyzers, the time of the detection can be a crucial piece of information, as a report may be a result of another preceding report. Users that record the timestamp of the detection and store it in CodeChecker under the new 'Timestamp' field will be able to sort reports by it. CodeChecker now also supports the 'Testsuite' field.
You can read more about this feature in its PR #3849, and the relevant docs PR #3871.
CodeChecker checkers --only-enabled DEPRECATED.
Show only the enabled checkers. use CodeChecker checkers --details to list the checker status (enabled/disabled)CodeChecker checkers --only-disabled.
use CodeChecker checkers --details to list the checker status.CodeChecker cmd diff -s, --suppressed DEPRECATED.
Lists the suppressed reports.--review-status [REVIEW_STATUS [REVIEW_STATUS ...]]
flag to filter the results.CodeChecker cmd diff --filter FILTER
Β Β Β DEPRECATED. Filter diff results.--review-status [REVIEW_STATUS [REVIEW_STATUS ...]]
flagCodeChecker cmd sum Β --disable-unique
Β DEPRECATED. Use the '--uniqueing' option to get uniqueing results.--tidy-config flag
Β #3822
CodeChecker analyze [--tidy-config TIDY_CONFIG]
DEPRECATED and removed.CodeChecker analyzers --analyzer-config clang-tidy
to list the analyzer optionsCodeChecker analyze --analyzer-config clang-tidy:WarningsAsErrors=true
to set a parameter.--enable/--disable
is not recognized (usually because of a typo) by any of the analyzers, CodeChecker now emits an error. While we strongly advise you against it, you can demote this error to a warning, restoring the behaviour similar to previous releases, with the flag --no-missing-checker-error
(#3866).bugprone-standalone-empty
: default, extreme, sensitivebugprone-unsafe-functions
: extreme, security, sensitivecert-msc24-c
: alias of bugprone-unsafe-functions
cert-msc33-c
: alias of bugprone-unsafe-functions
cppcoreguidelines-avoid-capture-default-when-capturing-this
: extreme, sensitivecppcoreguidelines-avoid-capturing-lambda-coroutines
: default, extreme, sensitivecppcoreguidelines-avoid-reference-coroutine-parameters
: default, extreme, sensitivecppcoreguidelines-rvalue-reference-param-not-moved
: extreme, sensitivellvmlibc-inline-function-decl
: stylemisc-use-anonymous-namespace
: default, extreme, sensitive# Analyze one source file.
CodeChecker analyze main.c -o reports
# analyze all source files under a directory.
CodeChecker analyze my_project -o reports
<analyzer>:<checker>:<option>=<value>
. This format is checked and an error message is emitted if the format is not met.lxml
to 4.9.1
#3799python3-setuptools
dependency #3729Published by bruntib over 1 year ago
After another round of optimizations, CodeChecker store
is ~2 times faster than in v6.21.0. Combined with the previous release, storing may be as much as 4 times faster than v6.20.0., with larger result directories seeing a greater degree of improvement.
This should allow those that use CodeChecker in CI loops to see fewer timeouts due to long storages, or lower timeout tresholds significantly.
CodeChecker now supports an analysis mode where for each source file, it tries to find the closest compile_commands.json file up in the directory hierarchy starting from the source file.
If your project is structured such that multiple folders act as their own root folder (hence the name multiroot), CodeChecker should be able to support that out of the box. clangd and clang-tidy already works this way:Β https://clangd.llvm.org/installation.html#compile_commandsjson
This feature also affects the CodeChecker Visual Studio Code plugin, where analysis will be done on multiroot projects as well Ericsson/CodecheckerVSCodePlugin#113.
Previously the input of analysis must have been a compilation database JSON file. This PR supports the following new CodeChecker analyze
invocations, as long as a corresponding compilation database file is found:
# Analyze a single file.
CodeChecker analyze analyze.cpp -o reports
# Analyze all source files under a directory.
CodeChecker analyze my_project -o reports
CodeChecker is now able to parse additional fields from plist files especially relevant to dynamic analyses.
<key>diagnostics</key>
<array>
<dict>
Β Β <key>category</key>
Β Β <string>Memory error</string>
Β Β ...
Β Β <dict>
Β Β Β Β <key>timestamp</key>
Β Β Β Β <string>2000-01-01 10:00</string>
Β Β Β Β <key>testsuite</key>
Β Β Β Β <string>TS-1</key>
Β Β Β Β ...
Β Β </dict>
</dict>
</array>
Unlike for static analyzers, the time of the detection can be a crucial piece of information, as a report may be a result of another preceding report. Users that record the timestamp of the detection and store it in CodeChecker under the new 'Timestamp' field will be able to sort reports by it. CodeChecker now also supports the 'Testsuite' field.
You can read more about this feature in its PR: #3849.
CodeChecker checkers --only-enabled DEPRECATED.
Show only the enabled checkers. use CodeChecker checkers --details to list the checker status (enabled/disabled)CodeChecker checkers --only-disabled.
use CodeChecker checkers --details to list the checker status.CodeChecker cmd diff -s, --suppressed DEPRECATED.
Lists the suppressed reports.--review-status [REVIEW_STATUS [REVIEW_STATUS ...]]
flag to filter the results.CodeChecker cmd diff --filter FILTER
Β Β Β DEPRECATED. Filter diff results.--review-status [REVIEW_STATUS [REVIEW_STATUS ...]]
flagCodeChecker cmd sum Β --disable-unique
Β DEPRECATED. Use the '--uniqueing' option to get uniqueing results.--tidy-config flag
Β #3822
CodeChecker analyze [--tidy-config TIDY_CONFIG]
DEPRECATED and removed.CodeChecker analyzers --analyzer-config clang-tidy
to list the analyzer optionsCodeChecker analyze --analyzer-config clang-tidy:WarningsAsErrors=true
to set a parameter.bugprone-standalone-empty
: default, extreme, sensitivebugprone-unsafe-functions
: extreme, security, sensitivecert-msc24-c
: alias of bugprone-unsafe-functions
cert-msc33-c
: alias of bugprone-unsafe-functions
cppcoreguidelines-avoid-capture-default-when-capturing-this
: extreme, sensitivecppcoreguidelines-avoid-capturing-lambda-coroutines
: default, extreme, sensitivecppcoreguidelines-avoid-reference-coroutine-parameters
: default, extreme, sensitivecppcoreguidelines-rvalue-reference-param-not-moved
: extreme, sensitivellvmlibc-inline-function-decl
: stylemisc-use-anonymous-namespace
: default, extreme, sensitive# Analyze one source file.
CodeChecker analyze main.c -o reports
# analyze all source files under a directory.
CodeChecker analyze my_project -o reports
<analyzer>:<checker>:<option>=<value>
. This format is checked and an error message is emitted if the format is not met.lxml
to 4.9.1
#3799python3-setuptools
dependency #3729Published by Szelethus almost 2 years ago
CodeChecker store
about twice as fast (#3777)CodeChecker store
command by as much as 50%!bugprone-assignment-in-if-condition
: extreme (no longer in the sensitive
and default
profiles)bugprone-signal-handler
: default (new), security (new), sensitive, extremebugprone-suspicious-realloc-usage
(new): default, sensitive, extremebugprone-stringview-nullptr
(new): default, sensitive, extremebugprone-unchecked-optional-access
(new): extremecert-sig30-c
: removed from all profiles (as it is an alias to bugprone-signal-handler)cppcoreguidelines-avoid-const-or-ref-data-members
: sensitive (new), extremecppcoreguidelines-avoid-do-while
(new): extrememisc-const-correctness
: removed from all profiles (it was too extreme even for extreme)misc-misleading-bidirectional
: default, security (new), sensitive, extrememisc-misleading-identifier"
(new): default, security, sensitive, extremealpha.unix.Errno
: sensitive (new), extremecore.uninitialized.NewArraySize
(new): default, sensitive, extremealpha.unix.cstring.UninitializedRead
(new): extreme--help
messages.README
(#3763)
CodeChecker cmd diff
to the server got an incorrect results, which this PR fixes.CodeChecker parse --export html
produced an invalid HTMl file.Published by Szelethus almost 2 years ago
CodeChecker store
about twice as fast (#3777)CodeChecker store
command by as much as 50%!bugprone-assignment-in-if-condition
: extreme (no longer in the sensitive
and default
profiles)bugprone-signal-handler
: default (new), security (new), sensitive, extremebugprone-suspicious-realloc-usage
(new): default, sensitive, extremebugprone-stringview-nullptr
(new): default, sensitive, extremebugprone-unchecked-optional-access
(new): extremecert-sig30-c
: removed from all profiles (as it is an alias to bugprone-signal-handler)cppcoreguidelines-avoid-const-or-ref-data-members
: sensitive (new), extremecppcoreguidelines-avoid-do-while
(new): extrememisc-const-correctness
: removed from all profiles (it was too extreme even for extreme)misc-misleading-bidirectional
: default, security (new), sensitive, extrememisc-misleading-identifier"
(new): default, security, sensitive, extremealpha.unix.Errno
: sensitive (new), extremecore.uninitialized.NewArraySize
(new): default, sensitive, extremealpha.unix.cstring.UninitializedRead
(new): extreme--help
messages.README
(#3763)
CodeChecker cmd diff
to the server got an incorrect results, which this PR fixes.CodeChecker parse --export html
produced an invalid HTMl file.Published by Szelethus about 2 years ago
--analyzer-config
options are given to CodeChecker then only the last one was taken into account. From this version both are handled: --analyzer-config <option1> --analyzer-config <option2>
. The old format is also still available: --analyzer-config <option1> <option2>
. This is especially useful when you specify the base analysis parameters in the codechecker_config file and you want to override certain parameters in the command line.Changed handling of in-code suppressions (e.g. //codechecker_suppress [ all ] This is a false warning) (#3580)
Review status is now connected to the individual reports instead of the (all reports) with the same report hash.
This makes it possible to mark a bug as a false positive on one branch (and store it in a run) and mark it as intentional on another branch.
Warning: The different handling of such rare cases can cause a change in the checker statistics.
Changed handing of suppressions in the GUI (#3646)
If you handle suppressions in the GUI instead of the source code, the suppressions remain effective for all reports identified by the same bug hash. These are called "suppression rules". You can list and manage such rules in the "Review Status Rules" window:
Changed visualization of false positive and intentional reports in the Oustanding Reports Statistics
Outstanding report statistics excluded false positive reports from the graphs even for time periods, when these reports were active. After this change, the reports will be counted in the outstanding reports graphs until the time they were classified as false positive. So you will be able to see a decreasing trend in the outstanding reports graph, after you classify reports false positive.
A new filter option has been introduced which returns all reports where the file is involved at any part of the bug path.
--trim-path-prefix
flag may now contain joker characters (#3674)--trim-path-prefix
flag helps to remove a given prefix of each file path during report storage. This prefix may now contain joker characters too. The longest matching prefix will be eliminated from each file path.clangtidy:take-config-from-directory=true
is specified (#3698)clangtidy:take-config-from-directory
is an analyzer config that makes ClangTidy get its arguments from a .clang-tidy
file, and only from thatCodeChecker cmd suppress run_name -i <import_file>
will only import suppressions for the run indicated by run_name
, and not all reports in all runs.CodeChecker cmd runs --details
(#3669).git
directory but the user who is running the CodeChecker store command doesn't have permission to this file then the storage failed.alpha.unix.Errno
: extremebugprone-assignment-in-if-condition
: default, sensitive, extrememisc-const-correctness
: extrememisc-confusable-identifiers
: default, sensitive, extrememodernize-macro-to-enum
: extremeREADME.md
(#3512)clang-extdef-mapping
utility during CTU analysis. This collects for each function definition in which file they have been defined. The format of this mapping file changed, and this change needs to be adapted in CodeChecker.dev_package
make target (#3682)CC_LIB_DIR
needs to be set to .../build/CodeChecker/lib/python3
directory.Published by bruntib about 2 years ago
--analyzer-config
options are given to CodeChecker then only the last one was taken into account. From this version both are handled: --analyzer-config <option1> --analyzer-config <option2>
. The old format is also still available: --analyzer-config <option1> <option2>
.Changed handling of in-code suppressions (e.g. //codechecker_suppress [ all ] This is a false warning) (#3580)
Review status is now connected to the individual reports instead of the (all reports) with the same report hash.
This makes it possible to mark a bug as a false positive on one branch (and store it in a run) and mark it as intentional on another branch.
Warning: The different handling of such rare cases can cause a change in the checker statistics.
Changed handing of suppressions in the GUI (#3646)
If you handle suppressions in the GUI instead of the source code, the suppressions remain effective for all reports identified by the same bug hash. These are called "suppression rules". You can list and manage such rules in the "Review Status Rules" window:
Changed visualization of false positive and intentional reports in the Oustanding Reports Statistics
Outstanding report statistics excluded false positive reports from the graphs even for time periods, when these reports were active. After this change, the reports will be counted in the outstanding reports graphs until the time they were classified as false positive. So you will be able to see a decreasing trend in the outstanding reports graph, after you classify reports false positive.
A new filter option has been introduced which returns all reports where the file is involved at any part of the bug path.
--trim-path-prefix
flag may now contain joker characters (#3674)--trim-path-prefix
flag helps to remove a given prefix of each file path during report storage. This prefix may now contain joker characters too. The longest matching prefix will be eliminated from each file path.clangtidy:take-config-from-directory=true
is specified (#3698)clangtidy:take-config-from-directory
is an analyzer config that makes ClangTidy get its arguments from a .clang-tidy
file, and only from thatCodeChecker cmd suppress run_name -i <import_file>
will only import suppressions for the run indicated by run_name
, and not all reports in all runs.CodeChecker cmd runs --details
(#3669).git
directory but the user who is running the CodeChecker store command doesn't have permission to this file then the storage failed.alpha.unix.Errno
: extremebugprone-assignment-in-if-condition
: default, sensitive, extrememisc-const-correctness
: extrememisc-confusable-identifiers
: default, sensitive, extrememodernize-macro-to-enum
: extremeREADME.md
(#3512)clang-extdef-mapping
utility during CTU analysis. This collects for each function definition in which file they have been defined. The format of this mapping file changed, and this change needs to be adapted in CodeChecker.dev_package
make target (#3682)CC_LIB_DIR
needs to be set to .../build/CodeChecker/lib/python3
directory.Published by csordasmarton over 2 years ago
--stats
flag (#3630, #3633)CodeChecker analyze
command has --stats
flag if there is at least one checker contating statisticsbased
in its name. We are using the checker listing function to determine the list of checkers but by default it excludes modeling checkers. This default behavior should be overridden when checking if underlying Clang supports statistics based checkers.-sdkroot
option to COMPILE_FLAGS structure (#3631)--sysroot
option, and CodeChecker is not aware of the option chosen by this downstreamcompile_commands.json
file.pyyaml
dependency to the web part to fix docker container (#3626)For more information check the milestone.
Published by csordasmarton over 2 years ago
CodeChecker version -o json
command wasn't a valid JSON format. From this release CodeChecker will provide a valid JSON output for this command.Clang Static Analyzer
checker is disabled in CodeChecker, clang is invoked with the analyzer-disable-checker
flag. This allows the user disabling core modeling checkers such as unix.DynamicMemoryModeling
. This causes malfunctioning of depending checkers.modeling
and debug
checkers (listed with clang -cc1 -analyzer-checker-help-developer
) will not be listed and cannot be disabled through CodeChecker with the --enable
and --disable
flags.--saargs
flag only.node
version (#3581, #3586)>=14.17.0
.print-steps
option to CodeChecker cmd diff
command (#3555)CodeChecker cmd diff
command which can be used to print bug steps similar what we are doing at the CodeChecker parse
command. This patch also solve the problem to print bug steps in HTML files for reports which comes from a CodeChecker server.--config
option which allow the configuration from an explicit configuration file. The parameters in the config file will be emplaced as command line arguments. Previously we supported only JSON
format but the limitation of this format is that we can't add comments in this file for example why we enabled/disabled a checker, why an option is important etc.YAML
format:
analyzer:
# Enable/disable checkers.
- --enable=core.DivideZero
For more information see the documentation.--file
and skipfile
option to be given together and analyze header file (#3616)--file
parameter to analyze single files. Large projects load in their configuration using the --config
parameter and if there is a -i skipfile
given in the config, CodeChecker analyze
call drops an error. From this release CodeChecker will allow -i skipfile
and --file
to be given together.--file
option CodeChecker under the hood will try to figure out which source files are depends on the given header file and we will analyze these source files.:
in run names with \:
(#3536):
character that does NOT separate a tag from a name. Commands such as server
and cmd results
accept :
as a literal in the name, but cmd diff
previously cut it as the "run tag" separator.TLS1
and TLS1.1
were deprecated in RFC8996. From this release CodeChecker will enforce the newer TLS1.2
or TLS1.3
.a.cpp
+ b.cpp
) the CodeChecker cmd diff
command in HTML format generated HTML files for each source file but inserted the same list of reports in all of the HTML files. From this release CodeChecker will insert only those reports to a generated HTML file which are really related to that file.doc_url
value's to absolute file paths in the CodeChecker checkers
output. This way other tools can open and view these documentation files easily.bugprone-shared-ptr-array-mismatch
: default
, extreme
, sensitive
misc-misleading-bidirectional
: default
, extreme
, sensitive
readability-container-contains
: default
, extreme
, sensitive
cppcoreguidelines-narrowing-conversions
: extreme
CodeChecker check
in case of exception (#3603).readability-duplicate-include
(#3592)--enable-all
(#3611)python-ldap
to 3.4.0
(#3550)lxml
to 4.7.1
(#3553)npm
packages (#3581, #3586)3.9.7
in docker image (#3591)For more information check the milestone.
We are proud to announce the official release of CodeChecker VSCode plugin.
6.18.2
or later and optionally add it to the PATH
environment variable.Published by csordasmarton almost 3 years ago
bugprone-easily-swappable-parameters
from sensitive
profile (#3579).CodeChecker cmd diff
when path trimming was used in the stored results.v-html
attribute on the UI side to dinamically rendering comments and analyzer commands. This can be very dangerous because it can easily lead to XSS vulnerabilities. To solve this problem the server will always return the escaped version of these values which can be safely rendered on the UI.CC_REPORT_URL
is defined and gerrit
format is used at CodeChecker parse
or CodeChecker cmd diff
commands, the output will contain the value of this environment variable wrapped inside quotes. When this output is sent to gerrit, it will convert URL links to HTML a
tags. Unfortunately gerrit will think that the ending quote is part of the URL, so it will not remove it. This way the URL will be invalid.For more information check the milestone.
Published by csordasmarton almost 3 years ago
markdownlint
(#3505).cppcoreguidelines-virtual-class-destructor
in profiles (#3532).bugprone-unhandled-exception-at-new
to default profile (#3531).--file
filter option for CodeChecker parse
command (#3454).6.18.0
release (#3530).CC_REPO
) for docker image (#3543).lxml
to 4.6.4
(#3528).For more information check the milestone.
CodeChecker can be installed and used from multiple repositories:
For more information see the installation guide.
CodeChecker can be used as a generic tool for visualizing analyzer results of multiple static and dynamic analyzers:
For details see supported code analyzers documentation and the Report Converter Tool.
Published by csordasmarton almost 3 years ago
The JSON
output of the CodeChecker parse command was not stable enough and the structure was very similar to the plist structure. Our plan is to support reading/parsing/storing of multiple analyzer output types not only plist but for example sarif format as well (http://docs.oasis-open.org/sarif/sarif/v2.0/csprd01/sarif-v2.0-csprd01.html). For this reason we changed the format of the JSON
output of the CodeChecker parse
and CodeChecker cmd diff
command. The new format is described in #3519.
Create a new global role (PERMISSION_VIEW
) which will be used to allow the users to fetch access control information from a running
CodeChecker server by using the CodeChecker cmd permissions
subcommand.
-mfp16-format
, -fmacro-prefix-map
, -fno-defer-pop
, -fstack-usage
flags (#3433, #3445).For more information check the milestone.
Published by csordasmarton about 3 years ago
With this feature it will be possible for a developer to check who modified the source line last where a CodeChecker error appears.
CodeChecker store
command will store blame information for every source files which are not stored yet.Cleanup plans can be used to track progress of reports in your product. The conception is similar to the github Milestones.
You can do the following:
If you want to use CodeChecker in your project but you don't want to run a CodeChecker server and to fix every reports found by CodeChecker for the first time (legacy findings) with this feature you can do the following:
./reports
).CodeChecker parse ./reports -e baseline -o reports.baseline
. Note: it is recommended to store this baseline file (reports.baseline
) in your repository.CodeChecker diff
command to get the new reports:CodeChecker cmd diff -b ./reports.baseline -n ./reports --new
The report-converter
tool is extended with LeakSanitizer which is a run-time memory leak detector for C programs.
# Compile your program.
clang -fsanitize=address -g lsan.c
# Run your program and redirect the output to a file.
ASAN_OPTIONS=detect_leaks=1 ./a.out > lsan.output 2>&1
# Generate plist files from the output.
report-converter -t lsan -o ./lsan_results lsan.output
# Store reports.
CodeChecker store ./lsan_results -n lsan
For more information see.
Previously the properties of checkers (severity, profile, guideline) are read from several JSON files. The goal was to handle all these and future properties of checkers in a common manner. This new solution uses labels which can be added to checkers.
The collection of labels is found in config/labels directory. The goal of these labels is that you can enable or disable checkers by these labels.
# List checkers in "sensitive" profile.
CodeChecker checkers --label profile:sensitive
# List checkers in "HIGH" severity.
CodeChecker checkers --label severity:HIGH
# List checkers covering str34-c SEI-CERT rule.
CodeChecker checkers --label sei-cert:str-34-c
# List checkers covering all SEI-CERT rules.
CodeChecker checkers --label guideline:sei-cert
# List available profiles, guidelines and severities.
CodeChecker checkers --profile
CodeChecker checkers --guideline
CodeChecker checkers --severity
# List labels and their available values.
CodeChecker checkers --label
CodeChecker checkers --label severity
# Enable HIGH checkers during analysis.
CodeChecker analyze \
./compile_commands.json \
-o ./reports
-e severity:HIGH
Note: with this new feature we also added severity levels for pylint (#3414) and cppcheck (#3415) analyzers.
Published by csordasmarton over 3 years ago
PyPI
package support (#3251, #3301).PyPI is the most commonly used central repository for Python packages. For this reason from this release we will provide an official PyPI package for CodeChecker. This PyPi package can be easily installed on both Unix and Windows based systems easily by using the pip
command: pip install codechecker
.
CodeChecker was extended with a tool that can capture compilation database of a Bazel
built product without actually performing compilation. For more information see.
CodeChecker cmd
(#3116)New command line options are introduced (CodeChecker cmd export
and CodeChecker cmd import
) which can be used to export comments and review status for a particular run in a JSON based format from a running CodeChecker server and import it to another server.
# Export data from one server.
CodeChecker cmd export -n myrun \
--url https://first-server.codechecker.com:443 2>/dev/null | python -m json.tool > myrun_export.json
# Import data to another server.
CodeChecker cmd import -i myrun_export.json --url https://second-server.codechecker.com:443
The report-converter
tool was extend with two more analyzers:
Sparse
which is a semantic checker for C programs; it can be used to find a number of potential problems with kernel code.CppLint
which is a lint-like tool which checks C++ code against Google C++ Style Guide.For more information see.
maximum CPU
resources by default during analysis (#3249).ccache
compiler detection (#3204).altera-unroll-loops
to the list of checkers (#3266).cyclic-import
and consider-iterating-dictionary
checks (#3314).Published by csordasmarton over 3 years ago
When a checker name and the alias of this checker is turned on, Clang Tidy (>=v11)
will generate only one report where the checker names are concatenated with ,
mark (e.g.: cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers). Unfortunately in previous CodeChecker releases we didn't handle this use case properly and we generated only one report from it. We changed this behaviour in #3238 so multiple reports will be generated for each checker name / alias if both are enabled.
From this release, the CodeChecker analyze
command will indicate only the success and failure of analysis by zero and non-zero exit codes respectively. Before, the analysis subcommand returned with 2
, if there was any report in the analysis. Form this release, it will return with 0
, if the analysis was successful irrespectively of the number of reports.
The CodeChecker parse
and CodeChecker cmd diff
subcommand will return with value 2
if there is at least one (not suppressed) report in the result set (#3232, #3255).
The return values of the subcommands is as follows:
CodeChecker analyze:
0 - Successful analysis
1 - CodeChecker error
3 - Analysis of at least one translation unit failed
128+signum - Terminating on a fatal signal whose number is signum
CodeChecker parse
0 - No report
1 - CodeChecker error
2 - At least one report emitted by an analyzer
CodeChecker check
0 - No report
1 - CodeChecker error
2 - At least one report emitted by an analyzer
3 - Analysis of at least one translation unit failed
128+signum - Terminating on a fatal signal whose number is signum
CodeChecker cmd diff
0 - No difference between baseline and newrun
1 - CodeChecker error
2 - There is at least one report difference between baseline and newrun