[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

Balogh, Ádám via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 15 07:37:39 PDT 2020


baloghadamsoftware added a comment.

In D77229#1980665 <https://reviews.llvm.org/D77229#1980665>, @NoQ wrote:

> Aha, ok, sounds like i thought that it's not worth it to inline the constructor for an argument when the call itself is not inlined, therefore i didn't model the construction context for this call. See also D49443#1193290 <https://reviews.llvm.org/D49443#1193290>. Your example shows that i was wrong to give up and this is something we should totally implement.
>
> The proper solution is to model the target region in `ExprEngine` as a parameter region based on the `ParmVarDecl` that //would have been used if the function was inlined//, instead of the dummy temporary. Then it'll be kept alive as an object under construction.
>
> The most annoying part is to make sure that you're using the same `FunctionDecl` consistently everywhere. If this turns out to be too annoying, we could also replace `VarRegion{ParmVarDecl}` with a new sort of region that doesn't include a specific `ParmVarDecl` but merely a parameter index (and maybe a type or a call site expr), so that not to bother with redeclarations; this is the right thing to do anyway.


I am trying to understand where I have to implement this but I have some problems. The first is that when a function is not inlined it does not have a `StackFrameContext`. What to use instead? I usually try to use the caller's stack frame but it seems to be incorrect and causes assertions. Or should we create a stack frame for non-inlined functions as well?

Where are the parameter regions created? In `case ConstructionContext::ArgumentKind` of function `ExprEngine::handleConstructionContext()`? Or in `CallEvent::getParameterLocation()`? Or somewhere else? I tried to look at D49443 <https://reviews.llvm.org/D49443>, especially the diff where you gave up regions for parameters of non-inlined functions but there you only had changes in `CallEvent`.

For using the same `FunctionDecl`: would it help if we always use the "first" `Decl` in the chain?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77229/new/

https://reviews.llvm.org/D77229





More information about the cfe-commits mailing list