balazske added inline comments.
================ Comment at: clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp:176-180 if (const auto *DeclReg = Reg->getAs<DeclRegion>()) { if (isa<ParmVarDecl>(DeclReg->getDecl())) Reg = C.getState()->getSVal(SV.castAs<Loc>()).getAsRegion(); + } else if (const auto *ParamReg = Reg->getAs<ParamRegion>()) { + Reg = C.getState()->getSVal(SV.castAs<Loc>()).getAsRegion(); ---------------- baloghadamsoftware wrote: > balazske wrote: > > baloghadamsoftware wrote: > > > Szelethus wrote: > > > > This is interesting. I looked up `DeclRegion`, and it seems to be the > > > > region that is tied to a `ValueDecl`. `VarDecl` is a subtype of > > > > `ValueDecl`, and `ParmVarDecl` is a subtype of `VarDecl`, so wouldn't > > > > it make sense for `ParamRegion` to be a subtype of `VarRegion`? > > > `DeclRegion` stores the `Decl`, `ParamRegion` retrieves it based on the > > > `Index` it stores. There is no is-a relation between them. > > During the lifetime of a `ParamRegion` is it possible that it will return > > different `Decl` objects? > @NoQ? Purpose of the question is that if the answer is "no", the decl could be stored at construction of a `ParamRegion` and it could be a subclass of `DeclRegion`. From the code I do not see that the belonging `Decl` can change, probably yes if the stack frame changes somehow. So the reason to have the `ParamRegion` seems to be to have the expression and index available, maybe use these for profiling (instead of a `Decl`). Still it could be made a subclass of `DeclRegion` that stores additionally the expr and index and profiling works with these values. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79704/new/ https://reviews.llvm.org/D79704 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits