clang ICE when decltype'ing a capture inside a lambda using deducing this

[foonathan]

Source:

void foo()
{
    int x;
    [x](this auto const&) { decltype(x) y; }();
}

Compile:

$ clang++ -std=c++23 test.cpp
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: /opt/compiler-explorer/clang-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++23 <source>
1.	<eof> parser at end of file
2.	Per-file LLVM IR generation
3.	<source>:4:5: Generating code for declaration 'foo()::(anonymous class)::operator()'
#0 0x0000000003b10418 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3b10418)
#1 0x0000000003b0e55c llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3b0e55c)
#2 0x0000000003a5d898 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x0000703df5242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x0000000006ef39dc clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6ef39dc)
#5 0x0000000006ede4eb clang::ASTContext::getTypeInfo(clang::Type const*) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6ede4eb)
#6 0x0000000006ef393f clang::ASTContext::getAlignOfGlobalVar(clang::QualType, clang::VarDecl const*) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6ef393f)
#7 0x00000000353ecd50 
clang++: error: clang frontend command failed with exit code 139 (use -v to see invocation)

https://godbolt.org/z/x6Pfh7Yqn

[Taw3e8]

This works on clang 18

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Jonathan Müller (foonathan)

Source:

void foo()
{
    int x;
    [x](this auto const&) { decltype(x) y; }();
}

Compile:

$ clang++ -std=c++23 test.cpp
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: /opt/compiler-explorer/clang-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++23 <source>
1.	<eof> parser at end of file
2.	Per-file LLVM IR generation
3.	<source>:4:5: Generating code for declaration 'foo()::(anonymous class)::operator()'
#<!-- -->0 0x0000000003b10418 llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3b10418)
#<!-- -->1 0x0000000003b0e55c llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3b0e55c)
#<!-- -->2 0x0000000003a5d898 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#<!-- -->3 0x0000703df5242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#<!-- -->4 0x0000000006ef39dc clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6ef39dc)
#<!-- -->5 0x0000000006ede4eb clang::ASTContext::getTypeInfo(clang::Type const*) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6ede4eb)
#<!-- -->6 0x0000000006ef393f clang::ASTContext::getAlignOfGlobalVar(clang::QualType, clang::VarDecl const*) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6ef393f)
#<!-- -->7 0x00000000353ecd50 
clang++: error: clang frontend command failed with exit code 139 (use -v to see invocation)

https://godbolt.org/z/x6Pfh7Yqn

[chrooti]

Introduced by 38824f2, to be precise:
if we hardcode IsDependent to false here the ICE disappears:

llvm-project/clang/lib/Sema/SemaExpr.cpp

Line 19958 in fc3ec13

auto IsDependent = [&]() {

The more I look at it the more this seems a blind spot in the standard:

• the implementation looks to be following the standard
• the assertion looks correct (but I don't know clang well enough)

So there is probably need for some wiggle room? In particular it should probably be the lambda type that is type dependent, not the capture itself, so it might be a defect in the standard?

I'd love to land a PR for this, does someone have any guidance on what the right behavior should be?

[cor3ntin]

@Sirraide @mizvekov

[Sirraide]

In particular it should probably be the lambda type that is type dependent, not the capture itself

Yeah, but since the capture is just a member access on the lambda type, it ends up being dependent as well since it could be e.g. either const int or int, depending on whether that lambda ends up being assigned to a const variable or not; we have some pretty horrible flags iirc in CXXThisExpr and DeclRefExpr to track dependence in lambdas w/ explicit object parameters; it’s definitely possible that there’s a bug in there somewhere.

[chrooti]

Should we perhaps resolve the dependent type around the place
FixDependencyOfIdExpressionsInLambdaWithDependentObjectParameter is called? Maybe with TemplateInstantiator or some other Sema TreeTransform?

might this also relate to #125582?