Unreachable with __unknown_anytype in CodeGen: "Unexpected placeholder builtin type!"

[gburgessiv]

Bugzilla Link	32900
Version	trunk
OS	All

Extended Description

Repro on trunk:

$ echo '__unknown_anytype foo; __unknown_anytype bar = foo;' | $clang -cc1 -x c++ -o - -S -emit-llvm - -funknown-anytype

Unexpected placeholder builtin type!
UNREACHABLE executed at ../../tools/clang/lib/CodeGen/CodeGenTypes.cpp:484!
#0 0x0000000001cd5a44 PrintStackTraceSignalHandler(void*) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1cd5a44)
#1 0x0000000001cd5d56 SignalHandler(int) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1cd5d56)
#2 0x00007f0216e6a330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#3 0x00007f0215a5ac37 gsignal /build/eglibc-MjiXCM/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x00007f0215a5e028 abort /build/eglibc-MjiXCM/eglibc-2.19/stdlib/abort.c:91:0
#5 0x0000000001c8d0cd llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1c8d0cd)
#6 0x0000000001f4725f clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1f4725f)
#7 0x0000000001f466e0 clang::CodeGen::CodeGenTypes::ConvertTypeForMem(clang::QualType) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1f466e0)
#8 0x0000000001e8beb7 clang::CodeGen::CodeGenModule::EmitNullConstant(clang::QualType) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1e8beb7)
#9 0x0000000001efb7bc clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(clang::VarDecl const*, bool) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1efb7bc)
#10 0x0000000001ef69e0 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1ef69e0)
#11 0x0000000001efdb31 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x1efdb31)
#12 0x000000000256ef10 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x256ef10)
#13 0x000000000256c42c clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x256c42c)
#14 0x0000000002a140a4 clang::ParseAST(clang::Sema&, bool, bool) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x2a140a4)
#15 0x0000000002221898 clang::FrontendAction::Execute() (/path/to/clang/llvm/llvm/build/release/bin/clang+0x2221898)
#16 0x00000000021e5d51 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x21e5d51)
#17 0x00000000022ab1f5 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x22ab1f5)
#18 0x000000000083c299 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/path/to/clang/llvm/llvm/build/release/bin/clang+0x83c299)
#19 0x000000000083a742 main (/path/to/clang/llvm/llvm/build/release/bin/clang+0x83a742)
#20 0x00007f0215a45f45 __libc_start_main /build/eglibc-MjiXCM/eglibc-2.19/csu/libc-start.c:321:0
#21 0x0000000000837439 _start (/path/to/clang/llvm/llvm/build/release/bin/clang+0x837439)
Stack dump:
0.      Program arguments: /path/to/clang/llvm/llvm/build/release/bin/clang -cc1 -x c++ -o - -S -emit-llvm - -funknown-anytype
1.      <stdin>:1:24: current parser token '__unknown_anytype'
2.      <stdin>:1:19: LLVM IR generation of declaration 'foo'
3.      <stdin>:1:19: Generating code for declaration 'foo'

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[Quuxplusone]

I've marked this [clang:frontend] because I believe the placeholder type is not supposed to be making it all the way into the codegen stage. Yesterday I discovered a similar problem with an UnknownAny placeholder making it further than it should. My test case won't reproduce on trunk; you have to edit getLValueReferenceType to include assert(!T->isPlaceholderType() && "Unresolved placeholder type") as its first line. But I claim (and @rjmccall in D118552 seemed to agree) that this should never happen.

extern __unknown_anytype var;
double *d = (double*)&var;

Clang says:

$ bin/clang++ -c -Xclang -funknown-anytype x.cpp
Assertion failed: (!T->isPlaceholderType() && "Unresolved placeholder type"), function getLValueReferenceType, file /tmp/llvm-project/clang/lib/AST/ASTContext.cpp, line 3375.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: bin/clang++ -c -Xclang -funknown-anytype x.cpp
1.	x.cpp:2:26: current parser token ';'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  clang++                  0x000000010d9564cd llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 61
1  clang++                  0x000000010d956a4b PrintStackTraceSignalHandler(void*) + 27
2  clang++                  0x000000010d95496a llvm::sys::RunSignalHandlers() + 138
3  clang++                  0x000000010d955d4e llvm::sys::CleanupOnSignal(unsigned long) + 110
4  clang++                  0x000000010d7e1b50 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) + 192
5  clang++                  0x000000010d7e1f43 CrashRecoverySignalHandler(int) + 195
6  libsystem_platform.dylib 0x00007fff677255fd _sigtramp + 29
7  libsystem_platform.dylib 0x00007ffee629e940 _sigtramp + 18446744071540544352
8  libsystem_c.dylib        0x00007fff675fb808 abort + 120
9  libsystem_c.dylib        0x00007fff675faac6 err + 0
10 clang++                  0x0000000112cbf78f clang::ASTContext::getLValueReferenceType(clang::QualType, bool) const + 127
11 clang++                  0x00000001131ae04f (anonymous namespace)::getStorageType(clang::ASTContext const&, clang::Expr const*) + 95
12 clang++                  0x00000001131ad8aa clang::Expr::EvaluateAsConstantExpr(clang::Expr::EvalResult&, clang::ASTContext const&, clang::Expr::ConstantExprKind) const + 634
13 clang++                  0x0000000113023d03 clang::computeDependence(clang::UnaryOperator*, clang::ASTContext const&) + 275
14 clang++                  0x000000011319361b clang::UnaryOperator::UnaryOperator(clang::ASTContext const&, clang::Expr*, clang::UnaryOperatorKind, clang::QualType, clang::ExprValueKind, clang::ExprObjectKind, clang::SourceLocation, bool, clang::FPOptionsOverride) + 251
15 clang++                  0x000000011319370d clang::UnaryOperator::UnaryOperator(clang::ASTContext const&, clang::Expr*, clang::UnaryOperatorKind, clang::QualType, clang::ExprValueKind, clang::ExprObjectKind, clang::SourceLocation, bool, clang::FPOptionsOverride) + 125
16 clang++                  0x000000011319380e clang::UnaryOperator::Create(clang::ASTContext const&, clang::Expr*, clang::UnaryOperatorKind, clang::QualType, clang::ExprValueKind, clang::ExprObjectKind, clang::SourceLocation, bool, clang::FPOptionsOverride) + 238
17 clang++                  0x0000000111d95806 clang::Sema::CreateBuiltinUnaryOp(clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*) + 5062
18 clang++                  0x0000000111d8b622 clang::Sema::BuildUnaryOp(clang::Scope*, clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*) + 434
19 clang++                  0x0000000111dbf573 clang::Sema::ActOnUnaryOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*) + 83
20 clang++                  0x000000011151f560 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) + 12784
21 clang++                  0x0000000111518cc9 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) + 89
22 clang++                  0x0000000111522d7a clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool, bool, clang::OpaquePtr<clang::QualType>&, clang::SourceLocation&) + 5354
23 clang++                  0x000000011151c52c clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) + 444
24 clang++                  0x0000000111518cc9 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) + 89
25 clang++                  0x0000000111517158 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 280
26 clang++                  0x000000011150296a clang::Parser::ParseInitializer() + 58

[rjmccall]

Hmm. In this case, I think it would probably be difficult to refactor the constant evaluator to avoid building a reference type, and it might be easier to just relax the assertion to allow this specific placeholder type. I don't love that because of the possibilities it creates for "escapes", but it's probably a more resilient approach than trying to chase down all the places in C++ type-checking that try to build reference types from expression types. But thank you for chasing this down; the example and stack trace was instrumentally helpful.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[AaronBallman]

The issue still reproduces as of Clang 16.0.0: https://godbolt.org/z/v8McTGdjY

[AaronBallman]

After some discussion, __unknown_anytype is intentionally an undocumented cc1-only interface which is only intended to support the needs of lldb for some debugging functionality. It is not a user-facing feature and any issues related to its direct use will be closed as Not a Bug (including crashes).

[rjmccall]

Hmm. It is true that __unknown_anytype is an internal feature for LLDB support, but we should take that support seriously. When we see reports of bugs with __unknown_anytype, we need to ask whether it corresponds to something that could plausibly happen in LLDB. That generally means: in the test case, is the type specifier being used in a position that LLDB would use it, which is to say, is the declaration something like __unknown_anytype x; or __unknown_anytype foo(...);? If so, and the distinguishing aspect of the test case is just the exact expression that uses the declaration, then that is probably something that someone could write in LLDB, which means it is a real bug in the LLDB expression parser and (thus) clang. I believe that applies here; my apologies to Aaron for not explaining this properly in our private communication.