[PATCH] D40560: [analyzer] WIP: Get construction into `operator new` running in simple cases.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 127420.
NoQ added a comment.

- Fix pop from empty stack.
- Add recursive operator new tests.
  - Disable argument invalidation when the allocator was inlined (needed for those tests to work)

In https://reviews.llvm.org/D40560#957653, @xazax.hun wrote:

> I think it would be great to have tests for such cases to make it apparent it is not trivial to do this only based on the cfg.
>  Maybe something like:
>
>   A *a = new A(new B, coin ? new C : new D, inlinedCallWithMoreAllocs()); 
>
>
> Or in case it turns out to be an easy problem to match these from CFG, I prefer avoiding the state.
>
> Also having a new expression within an overloaded operator new might be interesting.


Yeah, that's an excellent idea, thanks! I totally forgot about it.

Note, however, that neither chaining operator new as `new(new) C(...)` nor calling new from within the allocator actually makes our stack grow. In the former case, inner new-expression is fully evaluated before the outer new-expression even starts. In the latter case, the value for the outer allocator will only be put on stack after the outer allocator exits, after the inner new-expression is fully evaluated.

So in order to actually make use of the stack, we need to call operator new within a constructor that constructs into an outer operator new. In this case we first evaluate the outer allocator and put its results on the stack, then we evaluate the constructor and the operator new within it and put another value on the stack, and only then we pop both values.

See newly added tests for more details.

> Are you sure we need to produce undef vals? Couldn't a checker subscribe to the post allocator call and check for the undefined value and generate a sink before the constructor call? I am not opposed to using SVals there, just curious.

Yep, you're totally right. Now that we understand how these work, we can actually catch the undefined operator new return value in or just after the allocator. Other reasons still stand though.


https://reviews.llvm.org/D40560

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  test/Analysis/inline.cpp
  test/Analysis/new-ctor-conservative.cpp
  test/Analysis/new-ctor-inlined.cpp
  test/Analysis/new-ctor-recursive.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D40560.127420.patch
Type: text/x-patch
Size: 20364 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20171218/613b55e7/attachment-0001.bin>