Xazax-hun wrote:
> It's probably a good thing for storage locations to have types (because we
> want to be able to model the dynamic type of an object), but this probably
> means that we want to model addresses separately from storage locations.
Our knowledge of the dynamic type might change during the analysis. Consider
the following snippet:
```
void f(Base* b)
{
if (dynamic_cast<Derived*>(b)) {
// Here, we know that the dynamic type is (a subclass of) Derived
}
}
```
So, we either need to mutate storage locations, or we need to store the dynamic
types on the side. The Clang Static Analyzer (CSA) is doing the latter. While
CSA currently has types associated with the storage locations, we are
considering undoing this decision and make storage locations only represented
by sizes and offsets. We plan to always rely on the AST to determine the static
types, and use a data structure on the side to track the dynamic type
information.
That being said, for some frameworks having typed storage locations might be a
good idea, it is just not obvious to me where is the sweet spot and it will
need careful consideration. (And as far as I understand, we are not even sure
whether we want to switch to a different representation like access paths in
the future.)
> But all of this would be a major undertaking, I think.
Absolutely agree. The Clang Static Analyzer still has problems with type casts
in some cases, it is a really challenging problem. That being said, the CSA is
already immensely useful even with the partial modeling it has, so this is
probably one of the less pressing problems to solve in the near/medium term.
https://github.com/llvm/llvm-project/pull/75170
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
