Assertion failure in clang::Sema::BuildDelegatingInitializer

[hokein]

Bugzilla Link	39972
Version	trunk
OS	Linux
CC	@AaronBallman,@zygoloid

Extended Description

$ cat test-clang__Sema__BuildDelegatingInitializer.cc
class a {
struct b { operator a(
} template using c = b : a() : a(c()) {%
$ ./clang test-clang__Sema__BuildDelegatingInitializer.cc -std=c++17
test-clang__Sema__BuildDelegatingInitializer.cc:3:3: error: expected parameter declarator
} template using c = b : a() : a(c()) {
^
test-clang__Sema__BuildDelegatingInitializer.cc:3:3: error: expected ')'
test-clang__Sema__BuildDelegatingInitializer.cc:2:34: note: to match this '('
struct b { operator a(
^
test-clang__Sema__BuildDelegatingInitializer.cc:2:35: error: expected ';' at end of declaration list
struct b { operator a(
^
;
test-clang__Sema__BuildDelegatingInitializer.cc:3:4: error: expected ';' after struct
} template using c = b : a() : a(c()) {
^
;
test-clang__Sema__BuildDelegatingInitializer.cc:3:37: error: expected ';' after alias declaration
} template using c = b : a() : a(c()) {
^
;
test-clang__Sema__BuildDelegatingInitializer.cc:3:58: error: expected '}'
} template using c = b : a() : a(c()) {
^
test-clang__Sema__BuildDelegatingInitializer.cc:1:9: note: to match this '{'
class a {
^
WARNING: Logging before InitGoogle() is written to STDERR
F1212 11:27:25.973386 220045 logging.cc:82] assert.h assertion failed at third_party/llvm/llvm/include/llvm/Support/Casting.h:255 in typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = clang::CXXConstructExpr, Y = clang::Expr]: isa(Val) && "cast() argument of incompatible type!"
*** Check failure stack trace: ***
@ 0x559961def08b clang::Sema::BuildDelegatingInitializer()
@ 0x559961dee3a2 clang::Sema::BuildBaseInitializer()
@ 0x559961decc4a clang::Sema::BuildMemInitializer()
@ 0x559961ded4cd clang::Sema::ActOnMemInitializer()
@ 0x55996193027b clang::Parser::ParseMemInitializer()
@ 0x55996192f5ec clang::Parser::ParseConstructorInitializer()
@ 0x5599618cb7b1 clang::Parser::ParseLexedMethodDef()
@ 0x5599618ca175 clang::Parser::ParseLexedMethodDefs()
@ 0x559961928aa2 clang::Parser::ParseCXXMemberSpecification()
@ 0x559961926edf clang::Parser::ParseClassSpecifier()
@ 0x55996193f443 clang::Parser::ParseDeclarationSpecifiers()
@ 0x5599618b4c90 clang::Parser::ParseDeclOrFunctionDefInternal()
@ 0x5599618b49ec clang::Parser::ParseDeclarationOrFunctionDefinition()
@ 0x5599618b3637 clang::Parser::ParseExternalDeclaration()
@ 0x5599618b23ff clang::Parser::ParseTopLevelDecl()
@ 0x5599618b1f98 clang::Parser::ParseFirstTopLevelDecl()
@ 0x5599618ad1e5 clang::ParseAST()
@ 0x5599616d47a3 clang::FrontendAction::Execute()
@ 0x5599615561e1 clang::CompilerInstance::ExecuteAction()
@ 0x559960a2f5e5 clang::ExecuteCompilerInvocation()

[hokein]

assigned to @zygoloid

[llvmbot]

Richard, is this something you know about? Otherwise, could you redirect appropriately?

[zygoloid]

Reduced a bit more and cleaned up:

struct a {
struct b { operator a(); };
a() : a(b()) {}
};

... which is surprising BuildDelegatingInitializer because it expects the delegation target to be a constructor call rather than a direct call to a conversion function. (It actually should be a constructor call; we need to generate a call to the move constructor here rather than eliding the ctor call in case the conversion function would overwrite a vbase of the complete object.)

[AaronBallman]

Confirmed that the assertion still happens on trunk as of Clang 13.

[BengtGustafsson]

I still get this assert with latest clang main branch today, when compiling boost 1.81 (library url) using a debug-built clang. I build this via vcpkg, which outputs the clang internal error information into its log file (attached). Also attached is the preprocessed cpp file and corresponding .sh file. This command uses my own build of clang and includes the plugin I'm working on to support P2669. The compilation should give the same result with any recent debug compiled clang and without the plugin related switches. My fork of the clang repo is at: https://github.com/BengtGustafsson/llvm-project-UTP in case you want more details.

install-x64-linux-clang-dbg-out.log
src-d8adfb.sh.txt
src-d8adfb.cpp.txt

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[shafik]

it is a slightly different backtrace then the minimized version that Richard came up with: https://godbolt.org/z/dxbbq3zsr

but I think it is probably the same problem:

assert:

clang++: /root/llvm-project/llvm/include/llvm/Support/Casting.h:579: 
decltype(auto) llvm::cast(From*) [with To = clang::CXXConstructExpr; From = clang::Expr]: 
Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!"' failed.

backtrace:

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-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++17 <source>
1.	<source>:3:14: current parser token '{'
2.	<source>:1:1: parsing struct/union/class body 'a'
 #0 0x0000558c3e76ca7f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3fd3a7f)
 #1 0x0000558c3e76aa1c llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3fd1a1c)
 #2 0x0000558c3e6c49c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #3 0x00007f042f171420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x00007f042ec3e00b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
 #5 0x00007f042ec1d859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
 #6 0x00007f042ec1d729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729)
 #7 0x00007f042ec2efd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #8 0x0000558c411c84c7 clang::Sema::BuildDelegatingInitializer(clang::TypeSourceInfo*, clang::Expr*, clang::CXXRecordDecl*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6a2f4c7)
 #9 0x0000558c411cccf6 clang::Sema::BuildBaseInitializer(clang::QualType, clang::TypeSourceInfo*, clang::Expr*, clang::CXXRecordDecl*, clang::SourceLocation) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6a33cf6)
#10 0x0000558c411cd28b clang::Sema::BuildMemInitializer(clang::Decl*, clang::Scope*, clang::CXXScopeSpec&, clang::IdentifierInfo*, clang::OpaquePtr<clang::QualType>, clang::DeclSpec const&, clang::SourceLocation, clang::Expr*, clang::SourceLocation) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6a3428b)
#11 0x0000558c40e23a51 clang::Parser::ParseMemInitializer(clang::Decl*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x668aa51)
#12 0x0000558c40e25fb9 clang::Parser::ParseConstructorInitializer(clang::Decl*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x668cfb9)
#13 0x0000558c40dea518 clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6651518)
#14 0x0000558c40dea05d clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x665105d)
#15 0x0000558c40e34c4a clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::ParsedAttributes&, unsigned int, clang::Decl*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x669bc4a)
#16 0x0000558c40e36cc3 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::ParsedAttributes&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x669dcc3)
#17 0x0000558c40e0a8e0 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*, clang::ImplicitTypenameContext) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66718e0)
#18 0x0000558c40ddcbeb clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6643beb)
#19 0x0000558c40ddd50f clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (.part.0) Parser.cpp:0:0
#20 0x0000558c40de37f9 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x664a7f9)
#21 0x0000558c40de414d clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x664b14d)
#22 0x0000558c40de45f4 clang::Parser::ParseFirstTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x664b5f4)
#23 0x0000558c40dd806a clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x663f06a)
#24 0x0000558c3fae4ef8 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x534bef8)
#25 0x0000558c3f361699 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4bc8699)
#26 0x0000558c3f2e816e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4b4f16e)
#27 0x0000558c3f447433 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4cae433)
#28 0x0000558c3bc77cf4 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x14decf4)
#29 0x0000558c3bc73e37 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) driver.cpp:0:0
#30 0x0000558c3f151919 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#31 0x0000558c3e6c516a llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f2c16a)
#32 0x0000558c3f1521cf clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (.part.0) Job.cpp:0:0
#33 0x0000558c3f11b36c clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x498236c)
#34 0x0000558c3f11bded clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4982ded)
#35 0x0000558c3f12521c clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x498c21c)
#36 0x0000558c3bc76472 clang_main(int, char**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x14dd472)
#37 0x00007f042ec1f083 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24083)
#38 0x0000558c3bc6f0de _start (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x14d60de)
clang-16: error: clang frontend command failed with exit code 134 (use -v to see invocation)
Compiler returned: 134

[BengtGustafsson]

Looks to be the same yes. I recompiled clang in release mode (using gcc) and it can compile all of boost, so my suspicion is that the assert is too restrictive, or "real" errors would have cropped up given the simplicity of Richard's short snippet.

[DimitryAndric]

FWIW, the reproducer from #60182 is extremely simple:

// clang -cc1 -triple x86_64-- -S -O0 -std=c++17 boost-url-min.cpp

namespace urls {
struct segments_view {
  segments_view();
};
struct segments_encoded_view {
  operator segments_view();
} __trans_tmp_1;
segments_view::segments_view() : segments_view(__trans_tmp_1) {}
} // namespace urls

[DimitryAndric]

Oh, I now see that my minimized reproducer from boost is functionally the same as @zygoloid's in #39319 (comment), i.e.:

• one class with a default constructor
• another class that has conversion operator for the first class
• a delegating constructor making use of the conversion operator

So mine comes down to:

struct a {
  a();
};
struct b {
  operator a();
} c;
a::a() : a(c) {}

while Richard's version doesn't need the global variable:

struct a {
  struct b {
    operator a();
  };
  a() : a(b()) {}
};

Note that in both cases, -std=c++17 is needed to trigger the assertion, so there must be something different in the rules and/or path take in the parser, causing it.

[vangyzen]

I just hit this by compiling boost 1.81.0 with Clang 6.0.1 on FreeBSD 12.0, so the problem has been there a long time.

[zygoloid]

This will be caused by the "guaranteed copy elision" rule change in C++17. We shouldn't be considering conversion functions for delegating initialization, because we need an actual constructor call of the right kind (complete or base) in order to properly initialize the object.

[DimitryAndric]

I just hit this by compiling boost 1.81.0 with Clang 6.0.1 on FreeBSD 12.0, so the problem has been there a long time.

Note that we've only been seeing this assertion failure in FreeBSD since the boost ports were upgraded to 1.81.0, while the previous 1.80.0 built without issues. So the boost people have effectively added a similar construct as reported at the start of this bug (and which was already reported in 2018!).

[shafik]

@zygoloid any guidance on where to start if someone wanted to fix this issue?

[zygoloid]

The problematic consideration of conversion functions happens here:

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

Line 4028 in 1c417da

if (S.getLangOpts().CPlusPlus17 && Args.size() == 1 &&

We shouldn't be doing that when initializing a base or when delegating; see

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

Line 4106 in 1c417da

if (S.getLangOpts().CPlusPlus17 &&

for a place where we properly check that in the caller of the problematic function; I guess we should be passing in some kind of "require an actual constructor call" flag.

[shafik]

I am working on a fix taking @zygoloid comments into account and so far it looks good. I am going to run check-clang now and if it comes up clean I will post a draft PR and make sure it matches the intent in the comments and if that looks good I will clean it up.

[shafik]

So my approach was to add a new flag to ResolveConstructorOverload:

bool RequireActualConstructor,

and then use that check further down:

  if (S.getLangOpts().CPlusPlus17 && Args.size() == 1 &&
      RequireActualConstructor &&
       !SecondStepOfCopyInit) {

and at the call sites set the flag as such:

bool RequireActualConstructor = Entity.getKind() != InitializedEntity::EK_Base &&
      Entity.getKind() != InitializedEntity::EK_Delegating &&
      Entity.getKind() !=
          InitializedEntity::EK_LambdaToBlockConversionBlockElement;

This fixes the bug here but broke several tests:

Failed Tests (8):
  Clang :: CXX/dcl.dcl/dcl.attr/dcl.attr.nodiscard/p2.cpp
  Clang :: CXX/drs/dr19xx.cpp
  Clang :: CXX/over/over.match/over.match.viable/p3.cpp
  Clang :: CodeGenCXX/cxx1z-initializer-aggregate.cpp
  Clang :: CodeGenCXX/mangle-exprs.cpp
  Clang :: SemaCXX/cxx0x-initializer-constructor.cpp
  Clang :: SemaCXX/cxx1z-copy-omission.cpp
  Clang :: SemaTemplate/concepts-recursive-inst.cpp

I need to dig in and figure out if my check was too naive or if these tests are actually failing correctly and need to be updated.

[shafik]

It looks like I was bit overzealous in my initial change and a more narrow set of changes is looking better.

[shafik]

PR: https://reviews.llvm.org/D148474

@zygoloid Please let me know if this is the right approach

[shafik]

@yuanfang-chen I am hitting this unreachable code case, which came in with your change 632dd6a

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

Line 1068 in fdaf2f9

llvm_unreachable("unexpected deduction guide in instantiation stack");

in this test case I added in this PR: https://reviews.llvm.org/D148474

template<typename A3>
class B3 : A3 {
  template<bool = C3<B3>()> 
  B3();
}; B3(); 

It is not well-formed and I am guessing that somehow the C3<B3> is being mis-parsed and so we are hitting that unreachable code unexpectedly.

Any suggested fixes?

[shafik]

Currently blocked by: #65522

[chandankds]

Hello @shafik Thanks a lot for working on this issue, our boost build with c++17 is blocked due to this. I am aware that it might be difficult to answer but can you please comment on tentatively when it can be fixed ?

[yuanfang-chen]

@shafik could you please apply this on top of your patch? Thanks.
build-guide-ctx.patch

[shafik]

@shafik could you please apply this on top of your patch? Thanks. build-guide-ctx.patch

Ok, I put this up as a stand-alone fix: #67373

[DimitryAndric]

So how far are we with this bug? Is it now fixed as a consequence of #65522 landing in f1fed12 and #67373 landing in what seems to also have ended up as f1fed12 ?

[glebius]

Looks like the fix is not in 17.0.6. Is that correct?

[shafik]

Looks like the fix is not in 17.0.6. Is that correct?

I don't believe so, I did a quick check and I don't see it in the release notes.

[anzenchitai]

Still relevant.

[Endilll]

@anzenchitai Can you provide us with a reproducer (preferably on Compiler Explorer)?