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

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

1. Devin suggested a fantastic idea: it may be great to have a new `LocationContext` for whatever happens within the big-new-expression. This would help immensely with CFG look-aheads and look-behinds and reduce parent map usage - not only for operator new, but for other constructors (into initializer lists, probably into function arguments). Let's call it `ConstructionTriggerContext` for now. We can also store our "`_this`" value in a program state map from `ConstructionTriggerContext` into `SVal`.

2. My reaction was that we can instead store our "`_this`" value in some sort of "`CXX_ThisRegion`" within the `StackLocalsSpaceRegion` that corresponds to `ConstructionTriggerContext`, and then copy it over to `CXXThisRegion` that corresponds to the `StackFrameContext` of the constructor. This would kinda make sense given the pseudocode that we're imagine here for the new-expression. However, this sounds a bit over-engineered because we're using the Store to just temporarily stash the value. Well, right now we're using Environment for that, but it's equally dirty.

3. Now, it might actually be better to store "`_this`" value directly into `CXXThisRegion` that corresponds to the `StackFrameContext` of the constructor (rather than stash it in another place and eventually copy), even if that stack frame has not been entered yet. Because the stack frame would anyway be entered almost immediately, we already know the parameters of the stack frame (parent location context, call site, block count, block id, element id), and location contexts  are uniqued, so we can add the store binding now to the stack frame of the future, and whenever we actually enter the stack frame, when formerly we'd have bound the value to `CXXThisRegion`, we'd see that the value is already there. In this case we don't immediately need `ConstructionTriggerContext` - we can still add it later to refactor look-aheads and stuff. The binding would anyway be garbage-collected once the constructor exits.

I'd be glad to implement approach 3. instead of the stack of values if it sounds reasonable.


https://reviews.llvm.org/D40560