| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
to detect underfined behavior involving pointers.
llvm-svn: 210372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When binding a temporary object to a static local variable, the analyzer would
complain about a dangling reference even though the temporary's lifetime should
be extended past the end of the function. This commit tries to detect these
cases and construct them in a global memory region instead of a local one.
Reviewers: jordan_rose
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1133
llvm-svn: 187196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't appear to be the cause of the slowdown. I'll have to try a
manual bisect to see if there's really anything there, or if it's just
the bot itself taking on additional load. Meanwhile, this change helps
with correctness.
This changes an assertion and adds a test case, then re-applies r180638,
which was reverted in r180714.
<rdar://problem/13296133> and PR15863
llvm-svn: 180864
|
|
|
|
|
|
|
|
|
| |
This seems to be causing quite a slowdown on our internal analyzer bot,
and I'm not sure why. Needs further investigation.
This reverts r180638 / 9e161ea981f22ae017b6af09d660bfc3ddf16a09.
llvm-svn: 180714
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Casts to bool (and _Bool) are equivalent to checks against zero,
not truncations to 1 bit or 8 bits.
This improved reasoning does cause a change in the behavior of the alpha
BoolAssignment checker. Previously, this checker complained about statements
like "bool x = y" if 'y' was known not to be 0 or 1. Now it does not, since
that conversion is well-defined. It's hard to say what the "best" behavior
here is: this conversion is safe, but might be better written as an explicit
comparison against zero.
More usefully, besides improving our model of booleans, this fixes spurious
warnings when returning the address of a local variable cast to bool.
<rdar://problem/13296133>
llvm-svn: 180638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to r175830, which made sure a temporary object region
created for, say, a struct rvalue matched up with the initial bindings
being stored into it. This does the same for the case in which the AST
actually tells us that we need to create a temporary via a
MaterializeObjectExpr. I've unified the two code paths and moved a static
helper function onto ExprEngine.
This also caused a bit of test churn, causing us to go back to describing
temporary regions without a 'const' qualifier. This seems acceptable; it's
our behavior from a few months ago.
<rdar://problem/13265460> (part 2)
llvm-svn: 175854
|
|
|
|
|
|
| |
itself. Fixes <rdar://problem/13226577>.
llvm-svn: 175852
|
|
|
|
| |
llvm-svn: 162198
|
|
|
|
|
|
|
| |
Initializing a reference with itself, e.g. "int &a = a;" seems like a
very bad idea.
llvm-svn: 162093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a local variable, make sure we don't infinitely recurse when the
reference binds to itself.
e.g:
int* func() {
int& i = i; // assign non-exist variable to a reference which has same name.
return &i; // return pointer
}
rdar://11345441
llvm-svn: 155856
|
|
|
|
|
|
| |
handling in ExprEngine. Fixes <rdar://problem/10201666>.
llvm-svn: 140956
|
|
|
|
|
|
|
|
| |
Also convert stack-addr-ps.cpp to use the analyzer instead of just Sema, now
that it doesn't crash, and extract the stack-block test into another file since
it errors, and that prevents the analyzer from running.
llvm-svn: 138613
|
|
|
|
|
|
|
|
|
|
|
|
| |
label addresses or references to temporaries, e.g:
const int& g2() {
int s1;
int &s2 = s1; // expected-note {{binding reference variable 's2' here}}
return s2; // expected-warning {{reference to stack memory associated with local variable 's1' returned}}
}
llvm-svn: 120483
|
|
|
|
|
|
| |
hit when self-host.
llvm-svn: 120351
|
|
|
|
|
|
| |
The issue was brought to our attention by Matthieu Monrocq.
llvm-svn: 120331
|
|
convert values to an lvalue. This allows us to warn (again) about returning references to stack variables. (fixes PR 7812).
llvm-svn: 110242
|