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

[Balogh, Ádám via Phabricator via cfe-commits]

baloghadamsoftware marked an inline comment as done.
baloghadamsoftware added inline comments.


================
Comment at: clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1044
 
+class ParamWithoutVarRegion : public TypedValueRegion {
+  friend class MemRegionManager;
----------------
baloghadamsoftware wrote:
> baloghadamsoftware wrote:
> > NoQ wrote:
> > > There should be only one way to express the parameter region. Let's call this one simply `ParamRegion` or something like that, and `assert(!isa<ParmVarDecl>(D))` in the constructor of `VarRegion`.
> > Do you mean that we should use `ParamRegion` in every case, thus also when we have the definitioan for the function? I wonder whether it breaks too many things.
> This will surely not work. The common handling of `ParamVarDecl` and `VarDecl` is soo deeply rooted in the whole analyzer that separating them means creation of a totally new analyzer engine from scratch.
More specifically: whenever a function is inlined, its parameters are used as variables via `DeclRefExpr`s. A `DeclRefExpr` refers to a `Decl` which is a `ParamVarDecl` but that has reference neither for the `CallExpr` (since it is not related to the call, but to the `FunctionDecl` or `ObjCMethodDecl`) nore for its `Index` in the call. The former is the real problem that cannot be solved even on theoretical level: a function which is inlined cannot depend on the different `CallExpr`s where it is called. Even worse, if the function is analyzed top-level it has not `CallExpr` at all so using `ParamRegion` for its parameters is completely impossible.


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

https://reviews.llvm.org/D77229