| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the current implementation, we run visitors until the fixed point is
reached.
That is, if a visitor adds another visitor, the currently processed path
is destroyed, all diagnostics is discarded, and it is regenerated again,
until it's no longer modified.
This pattern has a few negative implications:
- This loop does not even guarantee to terminate.
E.g. just imagine two visitors bouncing a diagnostics around.
- Performance-wise, e.g. for sqlite3 all visitors are being re-run at
least 10 times for some bugs.
We have already seen a few reports where it leads to timeouts.
- If we want to add more computationally intense visitors, this will
become worse.
- From architectural standpoint, the current layout requires copying
visitors, which is conceptually wrong, and can be annoying (e.g. no
unique_ptr on visitors allowed).
The proposed change is a much simpler architecture: the outer loop
processes nodes upwards, and whenever the visitor is added it only
processes current nodes and above, thus guaranteeing termination.
Differential Revision: https://reviews.llvm.org/D47856
llvm-svn: 335666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: `getVariableNameFromRegion()` seems useless.
Reviewers: xazax.hun, george.karpenkov
Reviewed By: xazax.hun
Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D45081
llvm-svn: 328860
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
helper is used consistently
In most cases using
`N->getState()->getSVal(E, N->getLocationContext())`
is ugly, verbose, and also opens up more surface area for bugs if an
inconsistent location context is used.
This patch introduces a helper on an exploded node, and ensures
consistent usage of either `ExplodedNode::getSVal` or
`CheckContext::getSVal` across the codebase.
As a result, a large number of redundant lines is removed.
Differential Revision: https://reviews.llvm.org/D42155
llvm-svn: 322753
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D41538
llvm-svn: 321933
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It was written as "Memory Error" in most places and as "Memory error" in a few
other places, however it is the latter that is more consistent with
other categories (such as "Logic error").
rdar://problem/31718115
Differential Revision: https://reviews.llvm.org/D32702
llvm-svn: 302016
|
| |
|
|
|
|
|
|
|
| |
It looks like on some host-triples the result of a valist related expr can be
a LazyCompoundVal. Handle that case in the check.
Patch by Abramo Bagnara!
llvm-svn: 297619
|
| |
|
|
|
|
|
|
|
| |
This patch makes the valist check more robust to the different AST variants on
different platforms and also fixes a FIXME.
Differential Revision: https://reviews.llvm.org/D30157
llvm-svn: 297153
|
| |
|
|
|
|
|
| |
Simplifies and makes explicit the memory ownership model rather than
implicitly passing/acquiring ownership.
llvm-svn: 291143
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D15227
llvm-svn: 279427
|
| |
|
|
| |
llvm-svn: 279043
|
|
|
Differential Revision: https://reviews.llvm.org/D15227
llvm-svn: 279041
|