[PATCH] D16403: Add scope information to CFG

[Maxim Ostapenko via Phabricator via cfe-commits]

m.ostapenko added a comment.

Hi Artem,

In https://reviews.llvm.org/D16403#989451, @NoQ wrote:

> Hmm. @m.ostapenko @szepet @mgehre - I think it might be a good time to figure out if `ScopeBegin`/`ScopeEnd`, `LoopEntrance`/`LoopExit`, `LifetimeEnds`, `AutomaticObjectDtor` elements work nicely together. How should they be ordered with respect to each other?


Here are several observations about `ScopeBegin`/`ScopeEnd`, `LoopEntrance`/`LoopExit`, `LifetimeEnds`, `AutomaticObjectDtor` interaction:

1. `LifetimeEnds` and  `AutomaticObjectDtor` don't work together (I'm unable to tell why).
2. The difference between `ScopeBegin`/`ScopeEnd` and  `LifetimeEnds` was described by Devin several comments above, in short:
  - `LifetimeEnds` emits markers for when the lifetime of a C++ object in an automatic variable ends. For C++ objects with non-trivial destructors, this point is when the destructor is called. At this point the storage for the variable still exists, but what you can do with that storage is very restricted by the language because its contents have been destroyed.
  - `ScopeBegin`/`ScopeEnd` add markers for when the storage duration for the variable begins and ends. Hence I can conclude that `ScopeEnd` should reside after implicit destructors and `LifetimeEnds` markers in CFG.
3. `LoopEntrance`/`LoopExit` improve modelling of unrolled loops and I'm not sure whether scopes across iterations are the only thing that's modeled here.

> Is any of these scope representation a superset of another scope representation, or maybe fully covered by other two or three other scope representations?

Given my observations above, I'm not sure whether some representation can be fully covered by others -- all of them serve different purposes. Or perhaps I'm missing something?

> Would anybody be willing to produce some pictures (`-analyzer-checker debug.ViewCFG` and attach here) with current and/or intended behavior?

I'm attaching two CFGs for the following example:

  void test_for_implicit_scope() {
    for (A a; A b = a; )
      A c;
  }

  $ ./bin/clang -cc1 -fcxx-exceptions -fexceptions -analyze -analyzer-checker=debug.ViewCFG -analyzer-config cfg-scopes=true -analyzer-config cfg-loopexit=true -analyzer-config unroll-loops=true /tmp/scopes-cfg-output.cpp
  -> CFG-scopes-destructors-loopexit.dot
  
  $ ./bin/clang -cc1 -fcxx-exceptions -fexceptions -analyze -analyzer-checker=debug.ViewCFG -analyzer-config cfg-scopes=true -analyzer-config cfg-loopexit=true -analyzer-config cfg-lifetime=true -analyzer-config cfg-implicit-dtors=false /tmp/scopes-cfg-output.cpp
  -> CFG-scopes-loopexit-lifetime.dot{F5792940}
  
  {F5792939}



> Not sure, i guess `LifetimeEnds` is mostly used in `clang-tidy` so it does not necessarily need to work together with analyzer-specific elements (or maybe it's so great that we should switch to using it), but it would still be great if we had a single scope representation which would be rich enough to satisfy all needs.


Repository:
  rL LLVM

https://reviews.llvm.org/D16403