llvm/clang
Balazs Benics 11c3a21f8d [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)
2022-11-15 15:37:36 -08:00
..
bindings Strengthen -Wint-conversion to default to an error 2022-07-22 15:24:54 -04:00
cmake [CMake][Fuchsia] Enable assertions and backtraces in stage 1 build 2022-07-26 06:09:38 +00:00
docs Reenable POSIX builtin library functions in gnu2x mode 2022-11-10 16:55:23 -08:00
examples
include Downgrade implicit int and implicit function declaration to warning only 2022-09-15 09:10:15 +02:00
lib [analyzer] Workaround crash on encountering Class non-type template parameters 2022-11-15 15:37:36 -08:00
runtime
test [analyzer] Workaround crash on encountering Class non-type template parameters 2022-11-15 15:37:36 -08:00
tools [NFC] Fix a misleading comment CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION 2022-08-25 09:57:30 +02:00
unittests [clang][driver] Remove dynamic gcc-toolset/devtoolset logic 2022-10-27 22:01:32 -07:00
utils [clang][SVE] Undefine preprocessor macro defined in 2022-08-17 10:56:17 +02:00
www [clang] [docs] Update the changes of C++20 Modules in clang15 2022-07-26 18:47:53 +08:00
.clang-format
.clang-tidy
.gitignore
CMakeLists.txt Link libclangBasic against libatomic when necessary. 2022-11-10 17:04:34 -08:00
CODE_OWNERS.TXT
INSTALL.txt
LICENSE.TXT
ModuleInfo.txt
NOTES.txt
README.txt

//===----------------------------------------------------------------------===//
// C Language Family Front-end
//===----------------------------------------------------------------------===//

Welcome to Clang.  This is a compiler front-end for the C family of languages
(C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM
compiler infrastructure project.

Unlike many other compiler frontends, Clang is useful for a number of things
beyond just compiling code: we intend for Clang to be host to a number of
different source-level tools.  One example of this is the Clang Static Analyzer.

If you're interested in more (including how to build Clang) it is best to read
the relevant web sites.  Here are some pointers:

Information on Clang:             http://clang.llvm.org/
Building and using Clang:         http://clang.llvm.org/get_started.html
Clang Static Analyzer:            http://clang-analyzer.llvm.org/
Information on the LLVM project:  http://llvm.org/

If you have questions or comments about Clang, a great place to discuss them is
on the Clang forums:
  https://discourse.llvm.org/c/clang/

If you find a bug in Clang, please file it in the LLVM bug tracker:
  http://llvm.org/bugs/