| Age | Commit message (Collapse) | Author |
|---|
|
This check is introduced in
https://github.com/llvm/llvm-project/commit/b284005072122fe4af879725e3c8090009f89ca0,
but the documentation seems missing from `checkers.rst`.
|
|
|
|
|
|
PathRunningTime metric (#162839)
To avoid information loss, introduce a difference between unset stats
and 0 for statistics that are supposed to be set once per entry point.
Now, if the statistic is not set for an entry point, the corresponding
CSV cell will be empty, and not 0.
Thanks to this differentiation, I noticed that `PathRunningTime` was
actually never set, and fixed that.
Additionally, this patch enables the timers if
`DumpEntryPointStatsToCSV` is set, because in most cases you dump these
stats to get a detailed view on analyzer performance.
Finally, I added a dedicated debug checker that demonstrates the use of
a statistic and tested the set and unset scenarios explicitly.
--
CPP-7097
---------
Co-authored-by: Donát Nagy <donat.nagy@ericsson.com>
|
|
The complexity of maintaining an extra kind of metrics have not
justified itself, as it is not used upstream, and we have only a single
use of boolean stats per entrypoint downstream.
As I will do downstream, you can use an unsigned statistic type with
values 0 and 1 to model a boolean flag.
--
CPP-7097
|
|
This flag is really convinient in most cases.
It's easy to figure out what value to pass for most cases. However, it
can sometimes match too many times, like for template functions that has
non-decuded (aka. explicitly specified) template parameters - because
they don't appear in the parameter list, thus they are not accounted for
in the current logic.
It would be nice to improve `getFunctionName` but I'd say to just settle
on using USRs. So this PR enables passing USRs to the flag, while
keeping previous behavior.
|
|
Add the support for OSObjectPtr, which behaves like RetainPtr.
|
|
My recent commit a80c393a9c498279a1ec9fd630535b9ff139b49f accidentally
added a paragraph which does not belong to the new documentation of the
checker `security.VAList`; this commit corrects this mistake.
|
|
Previously the analyzer had an undocumented top-level checker group
called `valist` which offered several checkers to detect use of
uninitialized `va_list` objects and leaks of `va_list`s.
As the responsibilities of these checkers were messily intertwined and
`va_list` is a rarely used language feature, this commit simplifies the
situation by consolidating these checkers into a single checker which
will be called `security.VAList`.
Note that I'm choosing the capitalization `VAList` to be consistent with
the example of the AST node type `VAArgExpr`. I updated many variable
names to ensure that `ValistChecker.cpp` uses this spelling everywhere
(in CamelCased names). I'm planning to rename `ValistChecker.cpp` to
`VAListChecker.cpp` in a follow-up commit.
This commit also adds documentation for this checker in checkers.rst.
Among the test files I preserved the existing separation but I
eliminated some duplicated cases now that there is no way to separately
enable the old sub-checkers.
For the background of this change see also the discourse thread
https://discourse.llvm.org/t/clean-up-valist-checkers/85277/3
|
|
|
|
This adds alpha.core.StoreToImmutable, a new alpha checker that detects
writes
to immutable memory regions, implementing part of SEI CERT Rule ENV30-C.
The
original proposal only handled global const variables, but this
implementation
extends it to also detect writes to:
- Local const variables
- String literals
- Const parameters and struct members
- Const arrays and pointers to const data
This checker is the continuation of the work started by zukatsinadze.
Discussion: https://reviews.llvm.org/D124244
|
|
The documentation of the cross translation unit analysis mentioned a
certain flag of `CodeChecker` (an external open source tool that can be
used to drive the static analysis), but the information about it was
obsolete: apparently the name of the flag, the names of the possible
values, and the default value were all changed.
Currently `CodeChecker analyze --help` displays this flag as
```
--ctu-ast-mode {load-from-pch,parse-on-demand}
Choose the way ASTs are loaded during CTU analysis. Only available if
CTU mode is enabled. Mode 'load-from-pch' generates PCH format
serialized ASTs during the 'collect' phase. Mode 'parse-on-demand'
only generates the invocations needed to parse the ASTs. Mode 'load-
from-pch' can use significant disk-space for the serialized ASTs,
while mode 'parse-on-demand' can incur some runtime CPU overhead in
the second phase of the analysis. (default: parse-on-demand)
```
and I tried to follow this in the commands that I adjusted.
Note that this documentation file probably contains other obsolete
details as well, but I didn't try to find or fix them.
|
|
Changed the warning message:
- **From**: 'Attempt to free released memory'
**To**: 'Attempt to release already released memory'
- **From**: 'Attempt to free non-owned memory'
**To**: 'Attempt to release non-owned memory'
- **From**: 'Use of memory after it is freed'
**To**: 'Use of memory after it is released'
All connected tests and their expectations have been changed
accordingly.
Inspired by [this
PR](https://github.com/llvm/llvm-project/pull/147542#discussion_r2195197922)
|
|
This commit provides a brief documentation for the checker
optin.portability.UnixAPI.
Unfortunately the name of this checker is meaninglessly vague and its
functionality is very closely related to unix.Malloc, so it should be
eventually "rebranded" to a more user-friendly presentation.
|
|
(#145731)
Before this commit the LIT test framework of the static analyzer had a
file called `analyzer_test.py` which implemented a tricky system for
selecting the constraint manager:
- (A) Test files without `REQUIRES: z3` were executed with the default
range-based constraint manager.
- (B) If clang was built with Z3 support _and_ `USE_Z3_SOLVER=1` was
passed to the test run, the test was executed with Z3 as the
constraint manager.
(There was support for executing the same RUN line twice if both
conditions were satisfied.)
Unfortunately, using Z3 as the constraint manager does not work in
practice (very slow and causes many crashes), so the (B) pathway became
unused (or was never truly used?) and became broken due to bit rot. (In
the CI bots the analyzer is built without Z3 support, so only the
pathway (A) is used.)
This commit removes `analyzer_test.py` (+ related logic in other build
files + the test `z3/enabled.c` which just tested that
`analyzer_test.py` is active), because it tries to implement a feature
that we don't need (only one constraint manager is functional) and its
code is so complicated and buggy that it isn't useful as a starting
point for future development.
The fact that this logic was broken implied that tests with `REQUIRES:
z3` were not executed during normal testing, so they were also affected
by bit rot. Unfortunately this also affected the tests of the
`z3-crosscheck` mode (aka Z3 refutation) which also depends on Z3 but
uses Z3 in a different way which is actually stable and functional.
In this commit I'm fixing most of the `REQUIRES: z3` tests that were
broken by straightforward issues. Two test files, `PR37855.c` and
`z3-crosscheck.c` were affected by more complex issues, so I marked them
as `XFAIL` for now. We're planning to fix them with follow-up commits in
the foreseeable future.
For additional background information see also the discourse thread
https://discourse.llvm.org/t/taking-ownership-of-clang-test-analysis/84689
|
|
|
|
checker (#141232)
Resolves
https://github.com/llvm/llvm-project/issues/76208#issuecomment-2830854351
Quoting the docs of `[[clang::flag_enum]]`:
https://clang.llvm.org/docs/AttributeReference.html#flag-enum
> This attribute can be added to an enumerator to signal to the compiler that it
> is intended to be used as a flag type. This will cause the compiler to assume
> that the range of the type includes all of the values that you can get by
> manipulating bits of the enumerator when issuing warnings.
Ideally, we should still check the upper bounds but for simplicity let's not bother for now.
|
|
|
|
This commit documents the process of specifying values for the analyzer
options and checker options implemented in the static analyzer, and adds
a script which includes the documentation of the analyzer options (which
was previously only available through a command-line flag) in the
RST-based web documentation.
|
|
|
|
(#132404)
|
|
Oops, I noticed these just after merging my commit
9762b8e1757601a719d926f7df77c207617adfdd.
|
|
This commit documents `cplusplus.PureVirtualCall` (which was previously
completely undocumented) and improves the documentation of
`optin.cplusplus.VirtualCall` (which was very barebones).
Note that in this documentation I do not mention the checker options of
`optin.cplusplus.VirtualCall`, because `ShowFixIts` is apparently in an
unfinished alpha state (since 2019 when it was added by commit
6cee434ed10ead6b7416ca5ee9592b2b207eeb0f) and `PureOnly` is a deprecated
option that I'm going to remove very soon.
|
|
So far CSA was relying on the LLVM Statistic package that allowed us to
gather some data about analysis of an entire translation unit. However,
the translation unit consists of a collection of loosely related entry
points. Aggregating data across multiple such entry points is often
counter productive.
This change introduces a new lightweight always-on facility to collect
Boolean or numerical statistics for each entry point and dump them in a
CSV format. Such format makes it easy to aggregate data across multiple
translation units and analyze it with common data-processing tools.
We break down the existing statistics that were collected on the per-TU
basis into values per entry point.
Additionally, we enable the statistics unconditionally (STATISTIC ->
ALWAYS_ENABLED_STATISTIC) to facilitate their use (you can gather the
data with a simple run-time flag rather than having to recompile the
analyzer). These statistics are very light and add virtually no
overhead.
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
CPP-6160
|
|
declarations (#130554)
Add a new static analyzer which emits warnings for function call
arguments, local variables, and member variables that are only forward
declared. These forward declaration prevents other WebKit checkers from
checking the safety of code.
|
|
correct use of RetainPtr, adoptNS, and adoptCF (#128679)
Add a new WebKit checker to validate the correct use of RetainPtr
constructor as well as adoptNS and adoptCF functions. adoptNS and
adoptCf are used for +1 semantics and RetainPtr constructor is used for
+0 semantics.
|
|
Reland https://github.com/llvm/llvm-project/pull/130729
|
|
type call arguments." (#130828)
Reverts llvm/llvm-project#130729
|
|
call arguments. (#130729)
This PR adds alpha.webkit.UnretainedCallArgsChecker by generalizing
RawPtrRefCallArgsChecker. It checks call arguments of NS or CF types are
backed by a RetainPtr or not. The new checker emits warnings for CF
types in Objective-C++ code regardless of ARC and it emits warning for
NS types when ARC is disabled.
Hard-code a few cases as safe: class and superclass properties on class
interfaces and constant dictionary or array literals as well as the
return value of NSClassFromString.
Finally, add the support for variadic function calls and selector
invocations.
|
|
unretained member variables and ivars. (#128641)
Add a new WebKit checker for member variables and instance variables of
NS and CF types. A member variable or instance variable to a CF type
should be RetainPtr regardless of whether ARC is enabled or disabled,
and that of a NS type should be RetainPtr when ARC is disabled.
|
|
lambda capturing NS or CF types. (#128651)
Add a new WebKit checker for checking that lambda captures of CF types
use RetainPtr either when ARC is disabled or enabled, and those of NS
types use RetainPtr when ARC is disabled.
|
|
|
|
to NS and CF types. (#127554)
This PR adds alpha.webkit.UnretainedLocalVarsChecker by generalizing
RawPtrRefLocalVarsChecker. It checks local variables to NS or CF types
are guarded with a RetainPtr or not. The new checker is effective for NS
and CF types in Objective-C++ code without ARC, and it's effective for
CF types in code with ARC.
|
|
issues (#126724)
|
|
Before this commit, there were two alpha checkers that used different
algorithms/logic for detecting out of bounds memory access: the old
`alpha.security.ArrayBound` and the experimental, more complex
`alpha.security.ArrayBoundV2`.
After lots of quality improvement commits ArrayBoundV2 is now stable
enough to be moved out of the alpha stage. As indexing (and dereference)
are common operations, it still produces a significant amount of false
positives, but not much more than e.g. `core.NullDereference` or
`core.UndefinedBinaryOperatorResult`, so it should be acceptable as a
non-`core` checker.
At this point `alpha.security.ArrayBound` became obsolete (there is a
better tool for the same task), so I'm removing it from the codebase.
With this I can eliminate the ugly "V2" version mark almost everywhere
and rename `alpha.security.ArrayBoundV2` to `security.ArrayBound`.
(The version mark is preserved in the filename "ArrayBoundCheckerV2", to
ensure a clear git history. I'll rename it to "ArrayBoundChecker.cpp" in
a separate commit.)
This commit adapts the unit tests of `alpha.security.ArrayBound` to
testing the new `security.ArrayBound` (= old ArrayBoundV2). Currently
the names of the test files are very haphazard, I'll probably create a
separate followup commit that consolidates this.
|
|
Specifically, add a scope for
- each work-list step,
- each entry point,
- each checker run within a step, and
- bug-suppression phase at the end of the analysis of an entry-point.
These scopes add no perceptible run-time overhead when time-tracing is
disabled. You can enable it and generate a time trace using the
`-ftime-trace=file.json` option.
See also the RFC:
https://discourse.llvm.org/t/analyzer-rfc-ftime-trace-time-scopes-for-steps-and-entry-points/84343
--
CPP-6065
|
|
This commit fixes three issues within the documentation file
`Annotations.rst` which was recently created by my earlier commit
https://github.com/llvm/llvm-project/pull/122246 .
(1) The section title "Annotations to Enhance Generic Checks" is changed
to "General Purpose Annotations" because it was a bit too verbose and it
used the obsolete name "checks" for what we now call "checkers" in the
static analyzer.
(2) Several code blocks were missing from the generated html because I
accidentally used `.. code-block: c` instead of `.. code-block:: c` and
so Sphinx parsed them as comment blocks. (Without printing any error or
warning...)
(3) The `ownership_*` attributes (which are used by `MallocChecker`)
were missing from this document, so I wrote a section that briefly
describes them and links to their full documentation.
|
|
When commit 61a76f58ebf1 converted the static analyzer FAQ from HTML to
RST, it accidentally left out three images (`example_*.png`) that were
previously present in that document. This commit re-adds those three
images to the FAQ (and moves them to the directory for the image assets
of the RST documentation).
Moreover commit 093aaca2b0ad _copied_ the file `scan_build_cmd.png` to
the RST documentation directory instead of just moving it; so this
commit removes its "old" copy which is no longer used (because the old
HTML-based documentation file was replaced by a stub that redirects to
the RST docs).
|
|
This commit migrates the contents of 'annotations.html' in the old
HTML-based documentation of the Clang static analyzer to the new
RST-based documentation.
During this conversion I reordered the sections of this documentation
file by placing the section "Custom Assertion Handlers" as a subsection
of "Annotations to Enhance Generic Checks". (The primary motivation was
that Sphinx complained about inconsistent section levels; with this
change I preserved that sections describing individual annotations are
all on the same level.)
Apart from this change and the format conversion, I didn't review,
validate or edit the contents of this documentation file because I think
it would be better to place any additional changes in separate commits.
|
|
Forgot to mention these in the checker docs.
|
|
This PR introduces a new checker
`[alpha.webkit.MemoryUnsafeCastChecker]` that warns all downcasts from a base type to a derived type.
rdar://137766829
|
|
This change removes the alpha.core.IdenticalExpr static analysis checker
since it's checks are present in the clang-tidy checks
misc-redundant-expression and bugprone-branch-clone. This check was
implemented as a static analysis check using AST matching, and since
alpha and duplicated in 2 clang-tidy checks may be removed.
Co-authored-by: Vince Bridgers <vince.a.bridgers@ericsson.com>
|
|
This change modernizes, improves and promotes the chroot checker from
alpha to the Unix family of checkers. This checker covers the POS05
recommendations for use of chroot.
The improvements included modeling of a success or failure from chroot
and not falsely reporting a warning along an error path. This was made
possible through modernizing the checker to be flow sensitive.
---------
Co-authored-by: einvbri <vince.a.bridgers@ericsson.com>
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
|
|
of alpha (#113899)
|
|
(#114522)
This PR introduces alpha.webkit.UncheckedCallArgsChecker which detects a
function argument which is a raw reference or a raw pointer to a
CheckedPtr capable object.
|
|
CanMakeCheckedPtr. (#114636)
The member functions that define CheckedPtr capable type is
incrementCheckedPtrCount and decrementCheckedPtrCount after the rename.
|
|
This PR introduces alpha.webkit.UncheckedLocalVarsChecker which detects
a raw reference or a raw pointer local, static, or global variable to a
CheckedPtr capable object without a guardian variable in an outer scope.
|
|
tidy (#110471)
This change moves the `alpha.nondeterministic.PointerSorting` and
`alpha.nondeterministic.PointerIteration` static analyzer checkers to a
single `clang-tidy` check. Those checkers were implemented as simple
`clang-tidy` check-like code, wrapped in the static analyzer framework.
The documentation was updated to describe what the checks can and cannot
do, and testing was completed on a broad set of open-source projects.
Co-authored-by: Vince Bridgers <vince.a.bridgers@ericsson.com>
|
|
The ClangSA documentation lives in RST format, and the FAQ section of
the old webpage is also migrated from HTML with this change.
---------
Co-authored-by: Donát Nagy <donat.nagy@ericsson.com>
|
|
CommandLineUsage.rst (#112966)
|
