[clang] [analyzer] Fix crash in RegionStoreManager::bindArray (PR #210200)

[Balázs Benics via cfe-commits]

================
@@ -0,0 +1,39 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -std=c++17 -verify %s
+
+// https://github.com/llvm/llvm-project/issues/210183
+// Don't crash when binding a value that isn't a CompoundVal (e.g. a pointer
+// reinterpreted as an integer via a template-induced round trip) to a region
+// of array type.
+
+// expected-no-diagnostics
+
+template <typename T>
+class Span {
+public:
+  template <int N>
+  Span(T (&arr)[N]) : ptr_(arr) {}
+  T *data() { return ptr_; }
+  T *ptr_;
+};
+
+class Decoder {
+public:
+  template <typename TInput, typename TOutput>
+  auto decodeOne(TInput input, TOutput output) {
+    using InPtr_t = decltype(input.data());
+    InPtr_t inPtr = input.data();
+    using OutPtr_t = decltype(output.data());
+    OutPtr_t outPtr = output.data();
+    int scratch[1];
+    scratch[0] = *inPtr;
+    int value = scratch[0];
+    *outPtr = value;
+  }
+};
+
+void test() {
+  char buffer[1];
+  Span<char> span(buffer);
+  Decoder decoder;
+  decoder.decodeOne(span, span);
+}
----------------
steakhal wrote:

IMO part of the problem is that we hit the `bindAggregate` here. There are no assignments of aggregates in this example, so why? - I mean, we know why. The reason is because `buffer` and `p` should have the same value. `p` should have the value `&Element{buffer,0 S64b,char}`, so the question is, why does it hold a different value?

You can debug this by passing the `-analyzer-display-progress` to find the name of the entry point of the analysis; Then pass that as `-analyze-function='NAME()' -analyzer-dump-egraph=dump.dot`; then convert the dump to something human-readable using `clang/utils/analyzer/exploded-graph-rewriter.py dump.dot` and open the resulting HTML.

There you will see the different state transitions, and ultimately the analyzer_dump evaluations and their Environment (aka. registers), and the Store (aka. memory). Then trace it back up where the `p` was first present in the Store and then form a theory what caused it.

It's very likely that it will be the constructor of `Span<char>` in some Post event.
If I had to guess, this roots in the way we evaluate the initializer lists, but let's see what's going on.

---

> Happy to take a pass at that if you think it's the right direction

IMO it's too early to speculate about a fix.

https://github.com/llvm/llvm-project/pull/210200