[PATCH] D104550: [analyzer] Implement getType for SVal

Kristóf Umann via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 24 12:14:36 PDT 2021


Szelethus added a comment.

In D104550#2838845 <https://reviews.llvm.org/D104550#2838845>, @vsavchenko wrote:

>> Another thing is that we can garantee returning `QualType`. I mean, we can replace `Optional` with `QualType` itself. `QualType` has a default ctor and `isNull` predicate, which is //true// when defaultly constructed.
>
> I wanted to be more explicit here and convey to the user that the lack of type is normal.  I can change that, it won't be a problem at all.  @NoQ, @Szelethus what do you think?



  // May return nullptr.

And its all good!

In D104550#2835398 <https://reviews.llvm.org/D104550#2835398>, @NoQ wrote:

> Another thing to mention about `SVal::getType()` in its doxygen comment is that //most of the time you don't need it//. Similarly to how checking whether an `SVal` is a `Loc` or a `NonLoc` results in incorrect code 95% of the time (because such code is unable to discriminate between arbitrary lvalues and pointer rvalues which is typically crucial in order to get everything right but often forgotten / misunderstood), relying on the type of the `SVal` rather than its storage raises similar problems.

Then I especially can't imagine a more important doxygen comment then this! We could even consider adding your point about `Loc`s and `NonLoc`s to `SVal::getAs`. The target audience are new to clang, static analysis, and C++ itself. I recall you had to beat some of this stuff into me for weeks when I implemented pointer chasing in `UninitializedObjectChecker` :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550



More information about the cfe-commits mailing list