[PATCH] D79704: [Analyzer] [NFC] Parameter Regions

Kristóf Umann via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue May 12 05:20:37 PDT 2020


Szelethus added a comment.

In D79704#2029305 <https://reviews.llvm.org/D79704#2029305>, @baloghadamsoftware wrote:

> 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.


To me that sounds like a technicality. Sure, inheriting from `VarRegion` would make you carry around a field or two you may not need/use, but is that a big deal? To me it feels like all the problems you're solving should be an implementation detail. The interface of `ParamRegion` looks like a superset of `VarRegion`'s. The code changes suggests that every time we're interested in a `VarRegion`, we're also interested in parameters.

I may not see the obvious just yet, but I invite you to correct me! :)


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

https://reviews.llvm.org/D79704





More information about the cfe-commits mailing list