[PATCH] D86736: [analyzer][NFC] Don't bind values to ObjCForCollectionStmt, replace it with a GDM trait

Gabor Marton via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Sep 1 09:45:13 PDT 2020


martong added a comment.

I don't have anymore immediate concerns, but I will need more time to comb through the rest of the patch in more details... hopefully I can do that in the following days.



================
Comment at: clang/lib/StaticAnalyzer/Core/ProgramState.cpp:327
+using ObjCForLctxPair =
+    std::pair<const ObjCForCollectionStmt *, const LocationContext *>;
+
----------------
Szelethus wrote:
> martong wrote:
> > Why it is not enough to simply have ObjCForCollectionStmt* as a key?
> `Environment` is the data structure we use to bind **values** to **statements** (which would ideally be expressions only). The problem is that a statement on its own isn't enough to identify where we are in the analysis:
> 
> ```lang=c++
> void traverse(Graph &G) {
>  // SubG may need to be modeled in different stackframes, but has the same Stmt*
>  for (Graph &SubG : G->successors()) {
>     traverse(SubG);
>   }
> }
> ```
> 
> `LocationContext` can be thought of as a stack function calls (or anything with a distinct stack frame). Indeed, if two `(Stmt *, LocationContext *)` pairs are equal, we're rebinding the same expression (another loop iteration, goto), if only the statements are the same, we're not in the same function call (//stack frame//).
> 
> Of course `ObjCForCollectionStmt` can not have a value, that is the whole point of the patch, but we still need a `LocationContext` to correctly identify precisely which loop we're talking about.
Yeah, I did not think about stack frames, it makes perfect sense what you write, thanks for the explanation!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86736



More information about the cfe-commits mailing list