847f9cb0e8
Reland https://github.com/llvm/llvm-project/pull/75912 The differences of this PR between https://github.com/llvm/llvm-project/pull/75912 are: - Fixed a regression in `Decl::isInAnotherModuleUnit()` in DeclBase.cpp pointed by @mizvekov and add the corresponding test. - Fixed the regression in windows https://github.com/llvm/llvm-project/issues/97447. The changes are in `CodeGenModule::getVTableLinkage` from `clang/lib/CodeGen/CGVTables.cpp`. According to the feedbacks from MSVC devs, the linkage of vtables won't affected by modules. So I simply skipped the case for MSVC. Given this is more or less fundamental to the use of modules. I hope we can backport this to 19.x.
27 lines
835 B
C++
27 lines
835 B
C++
// RUN: rm -rf %t
|
|
// RUN: mkdir %t
|
|
// RUN: split-file %s %t
|
|
//
|
|
// RUN: %clang_cc1 -std=c++20 -triple i686-pc-windows-msvc %t/foo.cppm -emit-module-interface \
|
|
// RUN: -o %t/foo.pcm
|
|
// RUN: %clang_cc1 -std=c++20 -triple i686-pc-windows-msvc %t/user.cc -fmodule-file=foo=%t/foo.pcm \
|
|
// RUN: -emit-llvm -o - -disable-llvm-passes | FileCheck %t/user.cc
|
|
|
|
//--- foo.cppm
|
|
export module foo;
|
|
export struct Fruit {
|
|
virtual ~Fruit() = default;
|
|
virtual void eval();
|
|
};
|
|
|
|
//--- user.cc
|
|
import foo;
|
|
void test() {
|
|
Fruit *f = new Fruit();
|
|
f->eval();
|
|
}
|
|
|
|
// Check that the virtual table is an unnamed_addr constant in comdat that can
|
|
// be merged with the virtual table with other TUs.
|
|
// CHECK: unnamed_addr constant {{.*}}[ptr @"??_R4Fruit@@6B@", ptr @"??_GFruit@@UAEPAXI@Z", ptr @"?eval@Fruit@@UAEXXZ"{{.*}}comdat($"??_7Fruit@@6B@")
|