[PATCH] D152813: [clang][dataflow] Create `Value`s for integer literals.

[Martin Böhme via Phabricator via cfe-commits]

mboehme added a comment.

In D152813#4420445 <https://reviews.llvm.org/D152813#4420445>, @gribozavr2 wrote:

> In D152813#4420399 <https://reviews.llvm.org/D152813#4420399>, @mboehme wrote:
>
>> It looks to me as if the values we're now newly producing for integer literals are causing non-convergence of the analysis on the for-loop.
>
> For integer literals specifically, we should be returning the same value for the same literal over multiple loop iterations. And also, ideally, for multiple equal literals, too, so that an integer literal "42", no matter how many times spelled in the program, creates the same symbolic value.

That's true, and I'll modify the patch so that we do this. (I should probably also include a test that checks that `42 == 42` is equivalent to `true`.)

But even without this, wouldn't we expect the analysis to converge? The way I'm treating integer literals right now, the analysis is in effect "seeing" the example I quoted above like this:

  int return_some_random_int();
  void multiple_unchecked_accesses(absl::optional<int> opt1,
                                   absl::optional<int> opt2) {
    for (int i = return_some_random_int(); i < return_some_random_int(); i++) {
      opt1.value();
      // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: unchecked access to optional
    }
    opt2.value();
    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: unchecked access to optional value
  }

We would expect analysis of this code to converge too -- right? So I think the problem we're seeing here is independent of how we treat integer literals specifically (though I agree the same integer literal should always be represented by the same `Value`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152813