[PATCH] D79704: [Analyzer] [NFC] Parameter Regions
Balogh, Ádám via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon May 11 06:24:22 PDT 2020
baloghadamsoftware marked 2 inline comments as done.
baloghadamsoftware added a comment.
Thank you for quickly looking into this.
In D79704#2029230 <https://reviews.llvm.org/D79704#2029230>, @Szelethus wrote:
> - What identifies a `MemRegion`, `TypedValueRegion`s in particular? Why are parameters so special that they deserve their own region? Do you have a concrete, problematic example?
`ParamRegion` contains different data: mainly the index of the parameter. This makes it independent of the actual `Decl` of the parameter.
> - Why is it an issue that we don't always use the same declaration? Does this result in a crash, incorrect modeling?
See D49443#1193290 <https://reviews.llvm.org/D49443#1193290>.
> - Why are we making `ParamRegion` **not** a subclass of `VarRegion`?
Because `VarRegion` is a `DeclRegion` which stores the `Decl` of the variable. Here the main purpose is to not to store it.
> - The patch includes some code duplication, which may be okay, but do we need it?
Yes, and this comes from my previous answers.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountDiagnostics.cpp:435-442
+ const VarDecl *VD;
+ if (const auto *VR =
+ dyn_cast<VarRegion>(cast<SymbolRegionValue>(Sym)->getRegion())) {
+ VD = cast<VarDecl>(VR->getDecl());
+ } else if (const auto *PR =
+ dyn_cast<ParamRegion>(cast<SymbolRegionValue>(Sym)->getRegion())) {
+ VD = cast<ParmVarDecl>(PR->getDecl());
----------------
Szelethus wrote:
> Hmm. So, the surrounding code definitely suggests that we're definitely finishing for a parameter here, but it isn't always a parameter region? I know you struggled with this, have you gained any insight as to why?
Not all regions for `ParmVarDecl` are `ParamRegions`. Exceptions are parameters captured by a lambda or a block as well as parameters of functions analyzed top-level.
================
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();
----------------
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.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79704/new/
https://reviews.llvm.org/D79704
More information about the cfe-commits
mailing list