Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[doc] fixing spelling and gammar in usage guide #3636

Merged
merged 1 commit into from
Mar 24, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions docs/usage.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,8 @@ in your source code and integrate the static analysis into your CI flow to preve
- [Automatic fixing](#automatic-fixing)
- [Using incremental build on modified files](#using-incremental-build)
- [Using skip file to narrow analyzed files](#narrow-files)
- [Analyze explicitly selected source files from the compilation database](#analize-explicit-files)
- [Step 5: Cross Translation Unit analization](#step-5)
- [Analyze explicitly selected source files from the compilation database](#analyze-explicit-files)
- [Step 5: Cross Translation Unit Analysis](#step-5)
- [Step 6: Store analysis results in a CodeChecker DB and visualize results](#step-6)
- [Storage of multiple analysis report directories](#storage-of-multiple-analysis-report-directories)
- [Definition of "run"](#run-definition)
Expand Down Expand Up @@ -322,7 +322,7 @@ CodeChecker check --ignore skip.list --output ./reports --enable sensitive \
For more details regarding the skip file format see
the [user guide](analyzer/user_guide.md#skip).

#### Analyze explicitly selected source files from the compilation database <a name="analize-explicit-files"></a>
#### Analyze explicitly selected source files from the compilation database <a name="analyze-explicit-files"></a>
You can select which files you would like to analyze from the compilation
database. This is similar to the skip list feature but can be easier to quickly
analyze only a few files not the whole compilation database.
Expand All @@ -340,24 +340,24 @@ Absolute directory paths should start with `/`, relative directory paths should
start with `*` and it can contain path glob pattern. Example:
`/path/to/main.cpp`, `lib/*.cpp`, `*/test*`.

## Step 5: Cross Translation Unit analization <a name="step-5"></a>
The previous analization sessions did not follow dependencies between translation units. Make a try with CTU analysis. The `--ctu` option should be
added to analyze command. Choose an other "report-directory", for example
`./reports-ctu` to be able to compare output of different analysis configs.
## Step 5: Cross Translation Unit Analysis <a name="step-5"></a>
The previous analysis did not consider dependencies between translation units.
To enable a Cross Translation Unit (CTU) analysis, add the `--ctu` option
to the `analyze` command. In addition, choose another "report-directory", for
example `./reports-ctu`, to be able to compare the output of different analyses.

```sh
CodeChecker analyze ./compile_commands.json --output ./reports-ctu \
--enable sensitive --ctu
```

In this case the analyzer configuration enabled and we expect that the cross
translation unit checking found more issues.
Parse the output of the CTU analysis to check for newly detected issues.

```sh
CodeChecker parse --print-steps ./reports-ctu
```

The example code have an other bug!
The example code has another bug!

```sh
[HIGH] .../docs/examples/src/divide.c:5:22: Division by zero [core.DivideZero]
Expand Down Expand Up @@ -453,7 +453,7 @@ unique hash identifier that is independent of the line number, therefore
resistant to shifts in the source code. This way, newly introduced bugs can be
detected, compared to a central CodeChecker report database.

If you stored [first analization of unmodified](#run-the-analysis), example
If you stored the [first analysis of the unmodified](#run-the-analysis) example
project and made [automatic fixing](#automatic-fixing) then you can compare the
result between stored and locally analyzed example project.

Expand All @@ -476,7 +476,7 @@ CodeChecker fixit --checker-name bugprone-suspicious-string-compare --apply \

4. [Re-analyze your code](#using-incremental-build-on-modified-files). You are
well advised to use the same `analyze` options as you did in the first
analization session: the same checkers enabled, the same analyzer options, etc.
analysis session: the same checkers enabled, the same analyzer options, etc.
```sh
CodeChecker analyze ./compile_commands.json --output ./reports \
--enable sensitive
Expand All @@ -502,7 +502,7 @@ CodeChecker cmd diff --basename ./reports --newname ./reports-ctu --new
## Step 7: Fine tune Analysis configuration <a name="step-7"></a>
### Analysis Failures <a name="analysis-failures"></a>
The `reports/failed` folder contains all build-actions that were failed to
analyze. For these the clang tidy generates reports, clang static analizer
analyze. For these the clang tidy generates reports, clang static analyzer
will not.

Generally speaking, if a project can be compiled with Clang then the analysis
Expand Down