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.