[Modules] "Failed to find all of the visible " "constructors by walking all the " "lexical members of the context." with inheriting constructors + noncopyable class

[davidstone]

Given the following valid set of translation units:

export module a;

struct base {
	base(int) {}
};

export struct a : base {
	using base::base;
};

export module b;

import a;

a b() {
	return a(1);
}

export module c;

import a;
import b;

struct noncopyable {
	noncopyable(noncopyable const &) = delete;
};

struct c {
	noncopyable c0;
	a c1;
};

When compiled with

clang++ -std=c++20 -x c++-module --precompile -c a.cpp -o a.pcm
clang++ -std=c++20 -fmodule-file=a=a.pcm --precompile -x c++-module -c b.cpp -o b.pcm
clang++ -std=c++20 -fmodule-file=a=a.pcm -fmodule-file=b=b.pcm -x c++-module --precompile -c c.cpp -o /dev/null

Leads to an assertion failure of

clang++: llvm/clang/lib/Serialization/ASTWriter.cpp:3988: void clang::ASTWriter::GenerateNameLookupTable(const clang::DeclContext *, llvm::SmallVectorImpl<char> &): Assertion `ConstructorNameSet.empty() && "Failed to find all of the visible " "constructors by walking all the " "lexical members of the context."' failed.
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: clang++ -std=c++20 -fmodule-file=a=a.pcm -fmodule-file=b=b.pcm -x c++-module --precompile -c c.cpp -o /dev/null
1.      <eof> parser at end of file
 #0 0x00005561727296e1 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (clang+++0x41f16e1)
 #1 0x000055617272747e llvm::sys::RunSignalHandlers() (clang+++0x41ef47e)
 #2 0x0000556172728a41 llvm::sys::CleanupOnSignal(unsigned long) (clang+++0x41f0a41)
 #3 0x000055617269e5ab CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #4 0x00007fdf3a851f50 (/usr/lib/libc.so.6+0x38f50)
 #5 0x00007fdf3a8a08ec (/usr/lib/libc.so.6+0x878ec)
 #6 0x00007fdf3a851ea8 raise (/usr/lib/libc.so.6+0x38ea8)
 #7 0x00007fdf3a83b53d abort (/usr/lib/libc.so.6+0x2253d)
 #8 0x00007fdf3a83b45c (/usr/lib/libc.so.6+0x2245c)
 #9 0x00007fdf3a84a9f6 (/usr/lib/libc.so.6+0x319f6)
#10 0x0000556173605f40 clang::ASTWriter::GenerateNameLookupTable(clang::DeclContext const*, llvm::SmallVectorImpl<char>&) (clang+++0x50cdf40)
#11 0x0000556173606c4b clang::ASTWriter::WriteDeclContextVisibleUpdate(clang::DeclContext const*) (clang+++0x50cec4b)
#12 0x0000556173615b9d clang::ASTWriter::WriteASTCore(clang::Sema&, llvm::StringRef, clang::Module*) (clang+++0x50ddb9d)
#13 0x000055617361104f clang::ASTWriter::WriteAST(clang::Sema&, llvm::StringRef, clang::Module*, llvm::StringRef, bool, bool) (clang+++0x50d904f)
#14 0x0000556173663f68 clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&) (clang+++0x512bf68)
#15 0x0000556173495d4c clang::MultiplexConsumer::HandleTranslationUnit(clang::ASTContext&) (clang+++0x4f5dd4c)
#16 0x0000556174cee234 clang::ParseAST(clang::Sema&, bool, bool) (clang+++0x67b6234)
#17 0x00005561733e1a0e clang::FrontendAction::Execute() (clang+++0x4ea9a0e)
#18 0x00005561733490df clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (clang+++0x4e110df)
#19 0x00005561734cc091 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (clang+++0x4f94091)
#20 0x00005561712eab44 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (clang+++0x2db2b44)
#21 0x00005561712e62dd ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#22 0x00005561731b1cb9 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::$_1>(long) Job.cpp:0:0
#23 0x000055617269e2ac llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (clang+++0x41662ac)
#24 0x00005561731b10ad clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (clang+++0x4c790ad)
#25 0x000055617316ae85 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (clang+++0x4c32e85)
#26 0x000055617316b157 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (clang+++0x4c33157)
#27 0x000055617318b4a9 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (clang+++0x4c534a9)
#28 0x00005561712e5577 clang_main(int, char**, llvm::ToolContext const&) (clang+++0x2dad577)
#29 0x00005561712f7552 main (clang+++0x2dbf552)
#30 0x00007fdf3a83c790 (/usr/lib/libc.so.6+0x23790)
#31 0x00007fdf3a83c84a __libc_start_main (/usr/lib/libc.so.6+0x2384a)
#32 0x00005561712e22e5 _start (clang+++0x2daa2e5)
clang++: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 17.0.0 (https://github.com/llvm/llvm-project.git bf9e0ed1e61a407d7b0e133a9980cb8c29fc8ab0)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: build/bin
clang++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /tmp/c-1b679c.cppm
clang++: note: diagnostic msg: /tmp/c-1b679c.sh
clang++: note: diagnostic msg: 

[llvmbot]

@llvm/issue-subscribers-clang-modules

[zygoloid]

Fix re-landed in bc95f27.

[tbaederr]

@MaskRay Did you want to reopen this issue?

[ChuanqiXu9]

@MaskRay hi, would you like to provide a reproducer?

[ilya-biryukov]

I've added a reproducer and a fix in D148515.

[ilya-biryukov]

Unfortunately we hit another issue with the reland during the compiler releases. We see 'undefined symbol' errors from the linkers. I had to revert again, sorry for the trouble.

I will report back as soon as I have a repro or have a better idea of what's going on there.

[ilya-biryukov]

Just wanted to give an update that I still couldn't come up with a small repro here.
The rootcause seems to be that we do not run codegen for an instantiation of a member function coming from a module, but run codegen for a call to this function. This happens only in one particular TU that imports certain combination of template instantiations from other modules and instantiates their uses on its own.

[ChuanqiXu9]

@ilya-biryukov hi, are you still or planning to work on this?

[egorzhdan]

We're seeing this assertion failure when importing C++ headers into Swift for Swift/C++ interoperability.

Here's a small reproducer that doesn't use Swift (credits to @kateinoigakukun): apple#7661 (comment)

clang -x objective-c++-header -c include/B.h -o Prefix.pch.gch -isysroot path/MacOSX.sdk -fmodules -std=c++17