[PATCH] D115932: [Analyzer] Create and handle SymbolCast for pointer to integral conversion

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

Thanks for the review guys.

Artem, I agree, that we should remove `LocAsInteger`. `LocaAsInteger` is a primitive handling of a specific cast operation (when we cast a pointer to an integer). The integration of  `LocaAsInteger` into the `SymExpr` hierarchy is problematic as both this patch and its parent shows.

For precision, we should produce a `SymbolCast` when we evaluate a cast operation of a pointer to an integral type. I agree with Denys, that `makeSymExprValNN` is probably not the best place to do that. I took Denys' patch D105340 <https://reviews.llvm.org/D105340> and created a prototype on top of that to create the `SymbolCast` in `SValBuilder::evalCastSubKind(loc::MemRegionVal V,`.

  void test_param(int *p) {
    long p_as_integer = (long)p;
    clang_analyzer_dump(p);            // expected-warning{{&SymRegion{reg_$0<int * p>}}}
    clang_analyzer_dump(p_as_integer); // expected-warning{{(long) (reg_$0<int * p>)}}

I'd like to upload that soon.

Once we produce the `SymbolCast`s, then we can start handling them semantically. In my opinion, we should follow these steps:

1. Produce `SymbolCast`s. This is done in D105340 <https://reviews.llvm.org/D105340>, plus I am going to create another patch for pointer-to-int casts.
2. Handle `SymbolCast`s for the simplest cases. E.g. when we cast a (64bit width) pointer to a (64bit width unsigned) integer. This requires the foundation for an additional mapping in the `ProgramState` that can map a base symbol to cast symbols. This would be used in the constraint manager and this mapping must be super efficient.
3. Gradually handle more complex `SymbolCast` semantics. E.g. a widening cast.
4. Remove `LocAsInteger`. Produce the `SymbolCast`s by default and remove the option of `ShouldSupportSymbolicIntegerCasts`.

Point 2) and 3) are already started in D103096 <https://reviews.llvm.org/D103096>. But again, I think first we have to get the solid foundations with the `State` and with the `ConstraintManager` before getting into the more complex implementations of widening.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115932