Treat std::nullptr_t as a regular scalar type to avoid tripping
assertions when analyzing code that uses std::nullptr_t.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h | ||
|---|---|---|
| 96 | This is inconsistent with the change introduced by this patch. | |
| clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp | ||
| 27 | What does that mean? We are analyzing an incomplete translation unit? Why would the type ever be null here? | |
| clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h | ||
|---|---|---|
| 96 | Ah, you're correct. I can mail a fix out later today. | |
| clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp | ||
| 27 | See the motivating test case: // Alternatively, use `std::nullptr_t` instead of `my_nullptr_t`. using my_nullptr_t = decltype(nullptr); my_nullptr_t Null = 0; This triggers getOrCreateNullPointerValue to be called with a null pointee type. | |
This is inconsistent with the change introduced by this patch.