[all-commits] [llvm/llvm-project] 11c3a2: [analyzer] Workaround crash on encountering Class ...

[Balazs Benics via All-commits]

  Branch: refs/heads/release/15.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 11c3a21f8d1ba21c7744ba9d272c26c2ce3c58a0
      https://github.com/llvm/llvm-project/commit/11c3a21f8d1ba21c7744ba9d272c26c2ce3c58a0
  Author: Balazs Benics <benicsbalazs at gmail.com>
  Date:   2022-11-15 (Tue, 15 Nov 2022)

  Changed paths:
    M clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
    A clang/test/Analysis/template-param-objects.cpp

  Log Message:
  -----------
  [analyzer] Workaround crash on encountering Class non-type template parameters

The Clang Static Analyzer will crash on this code:
```lang=C++
struct Box {
  int value;
};
template <Box V> int get() {
  return V.value;
}
template int get<Box{-1}>();
```
https://godbolt.org/z/5Yb1sMMMb

The problem is that we don't account for encountering `TemplateParamObjectDecl`s
within the `DeclRefExpr` handler in the `ExprEngine`.

IMO we should create a new memregion for representing such template
param objects, to model their language semantics.
Such as:
 - it should have global static storage
 - for two identical values, their addresses should be identical as well
http://eel.is/c%2B%2Bdraft/temp.param#8

I was thinking of introducing a `TemplateParamObjectRegion` under `DeclRegion`
for this purpose. It could have `TemplateParamObjectDecl` as a field.

The `TemplateParamObjectDecl::getValue()` returns `APValue`, which might
represent multiple levels of structures, unions and other goodies -
making the transformation from `APValue` to `SVal` a bit complicated.

That being said, for now, I think having `Unknowns` for such cases is
definitely an improvement to crashing, hence I'm proposing this patch.

Reviewed By: xazax.hun

Differential Revision: https://reviews.llvm.org/D135763

(cherry picked from commit b062ee7dc4515b0a42157717105839627d5542bb)