| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.
By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.
<rdar://problem/13978414>
llvm-svn: 182677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new edge algorithm would keep track of the previous location in each
location context, so that it could draw arrows coming in and out of each
inlined call. However, it tried to access the location of the call before
it was actually set (at the CallEnter node). This only affected
unterminated calls at the end of a path; calls with visible exit nodes
already had a valid location.
This patch ditches the location context map, since we're processing the
nodes in order anyway, and just unconditionally updates the PrevLoc
variable after popping out of an inlined call.
<rdar://problem/13983470>
llvm-svn: 182676
|
|
|
|
| |
llvm-svn: 182589
|
|
|
|
|
|
| |
get removed.
llvm-svn: 182562
|
|
|
|
| |
llvm-svn: 182514
|
|
|
|
| |
llvm-svn: 182509
|
|
|
|
| |
llvm-svn: 182506
|
|
|
|
|
|
|
|
| |
text.
Fixes <rdar://problem/13949982>
llvm-svn: 182505
|
|
|
|
|
|
|
|
|
|
|
| |
than 3 columns.
These are legitimate control-flow edges, but visually they add
no value.
Implements <rdar://problem/13941325>.
llvm-svn: 182502
|
|
|
|
| |
llvm-svn: 182501
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, blocks instantiated in templates lose their "signature as
written"; it's not clear if this is intentional. Change the analyzer's
use of BlockDecl::getSignatureAsWritten to check whether or not the
signature is actually there.
<rdar://problem/13954714>
llvm-svn: 182497
|
|
|
|
|
|
|
|
|
| |
The crash is triggered by the newly added option (-analyzer-config report-in-main-source-file=true) introduced in r182058.
Note, ideally, we’d like to report the issue within the main source file here as well.
For now, just do not crash.
llvm-svn: 182445
|
|
|
|
|
|
|
|
| |
dive-in and out of a subexpression.
Fixes <rdar://problem/13941891>.
llvm-svn: 182426
|
|
|
|
|
|
| |
does.
llvm-svn: 182425
|
|
|
|
|
|
| |
Fixes <rdar://problem/13942300>.
llvm-svn: 182342
|
|
|
|
| |
llvm-svn: 182188
|
|
|
|
|
|
| |
Originally implemented by Ted, extended by me.
llvm-svn: 182186
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PseudoObjectExprs."
Ted and I spent a long time discussing this today and found out that neither
the existing code nor the new code was doing what either of us thought it
was, which is never good. The good news is we found a much simpler way to
fix the motivating test case (an ObjCSubscriptExpr).
This reverts r182083, but pieces of it will come back in subsequent commits.
llvm-svn: 182185
|
|
|
|
| |
llvm-svn: 182156
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This optimizes some spurious edges resulting from PseudoObjectExprs.
This required far more changes than I anticipated. The current
ParentMap does not record any hierarchy information between
a PseudoObjectExpr and its *semantic* expressions that may be
wrapped in OpaqueValueExprs, which are the expressions actually
laid out in the CFG. This means the arrow pruning logic could
not map from an expression to its containing PseudoObjectExprs.
To solve this, this patch adds a variant of ParentMap that
returns the "semantic" parentage of expressions (essentially
as they are viewed by the CFG). This alternate ParentMap is then
used by the arrow reducing logic to identify edges into pseudo
object expressions, and then eliminate them.
llvm-svn: 182083
|
|
|
|
|
|
|
|
|
| |
'for' or 'while'.
This means adding an extra edge from the 'if' to the condition,
which aesthetically looks more pleasing.
llvm-svn: 182079
|
|
|
|
|
|
|
|
| |
function
for a nested call. This matches what we do with the first stack frame.
llvm-svn: 182078
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The analyzer can't see the reference count for shared_ptr, so it doesn't
know whether a given destruction is going to delete the referenced object.
This leads to spurious leak and use-after-free warnings.
For now, just ban destructors named '~shared_ptr', which catches
std::shared_ptr, std::tr1::shared_ptr, and boost::shared_ptr.
PR15987
llvm-svn: 182071
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the report location.
Previously, we’ve used the last location of the analyzer issue path as the location of the
report. This might not provide the best user experience, when one analyzer a source
file and the issue appears in the header. Introduce an option to use the last location
of the path that is in the main source file as the report location.
New option can be enabled with -analyzer-config report-in-main-source-file=true.
llvm-svn: 182058
|
|
|
|
|
|
|
|
|
|
|
| |
ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)
llvm-svn: 181832
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
llvm-svn: 181677
|
|
|
|
|
|
|
| |
In most cases it is, by just looking at the name. Also, this check prevents the heuristic from working in strange user settings.
radar://13839692
llvm-svn: 181615
|
|
|
|
|
|
| |
to the closing '}'
llvm-svn: 181505
|
|
|
|
| |
llvm-svn: 181504
|
|
|
|
|
|
| |
conditions.
llvm-svn: 181385
|
|
|
|
|
|
| |
to retain
llvm-svn: 181384
|
|
|
|
|
|
| |
when handling interprocedural paths.
llvm-svn: 181362
|
|
|
|
|
|
| |
edge.
llvm-svn: 181361
|
|
|
|
| |
llvm-svn: 181360
|
|
|
|
| |
llvm-svn: 181359
|
|
|
|
| |
llvm-svn: 181358
|
|
|
|
|
|
| |
adds no value.
llvm-svn: 181357
|
|
|
|
|
|
| |
either.
llvm-svn: 181356
|
|
|
|
|
|
| |
Instead, use the location of the call to print the note.
llvm-svn: 181337
|
|
|
|
|
|
| |
for arrows.
llvm-svn: 181333
|
|
|
|
|
|
| |
control-flow conditions to prune edges.
llvm-svn: 181292
|
|
|
|
|
|
| |
for 'entering loop body'
llvm-svn: 181291
|
|
|
|
|
|
| |
the first time.
llvm-svn: 181282
|
|
|
|
|
|
|
|
|
| |
deleted the next iterator.
This is an optimization. It is possible that by deleting the next
edge we will pattern match again at the current spot.
llvm-svn: 181256
|
|
|
|
|
|
|
|
| |
The one user has been changed to use getLValue on the compound literal
expression and then use the normal bindLoc to assign a value. No need
to special case this in the StoreManager.
llvm-svn: 181214
|
|
|
|
|
|
|
|
|
|
|
|
| |
This occurs because in C++11 the compound literal syntax can trigger a
constructor call via list-initialization. That is, "Point{x, y}" and
"(Point){x, y}" end up being equivalent. If this occurs, the inner
CXXConstructExpr will have already handled the object construction; the
CompoundLiteralExpr just needs to propagate that value forwards.
<rdar://problem/13804098>
llvm-svn: 181213
|
|
|
|
|
|
| |
to prevent an edge being optimized away.
llvm-svn: 181088
|
|
|
|
| |
llvm-svn: 181087
|
|
|
|
|
|
| |
parents and subexpressions.
llvm-svn: 181086
|
|
|
|
|
|
| |
subexpression and pop back out.
llvm-svn: 181085
|