NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.
Just in case: we indeed do not guarantee that `SymbolConjured` corresponds to a
statement; it is, however, not intended, but rather a bug. Consider:
1 void clang_analyzer_eval(bool);
2
3 class C {
4 int &x;
5 public:
6 C(int &x): x(x) {}
7 ~C();
8 };
9
10 void foo() {
11 int x = 1;
12 {
13 C c(x);
14 }
15 int y = x;
16 {
17 C c(x);
18 }
19 int z = x;
20 clang_analyzer_eval(y == z);
21 }
We currently evaluate `clang_analyzer_eval(y == z)` to `TRUE` but that's
unsound because `~C();` could have been defined as `~C() { ++x; }`. We make
such unsound assumption because `SymbolConjured` put into `x` during destructor
call on line 14 and on line 18 is the same conjured symbol because they have no
statements attached because destructors are implicit and have no corresponding
statements, and everything else about these two symbols is the same. So, well,
we should work around this problem somehow.
----
Now the real question here is whether `IteratorChecker` should scan any of the
symbols that have no statement attached. I believe that `IteratorChecker`
should only be interested in symbols that were returned from specific functions
that return iterators. In the test case there are no iterators at all, so i
suspect that the iterator checker is scanning more symbols than it needs.
----
Regardless, the patch makes sense :)
Repository:
rC Clang
https://reviews.llvm.org/D44606
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
