[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

[David Blaikie via cfe-commits]

================
@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const CXXRecordDecl *RD) {
       TSK == TSK_ExplicitInstantiationDefinition)
     return false;
 
+  // Itanium C++ ABI [5.2.3]:
+  // Virtual tables for dynamic classes are emitted as follows:
+  //
+  // - If the class is templated, the tables are emitted in every object that
+  // references any of them.
+  // - Otherwise, if the class is attached to a module, the tables are uniquely
+  // emitted in the object for the module unit in which it is defined.
+  // - Otherwise, if the class has a key function (see below), the tables are
+  // emitted in the object for the translation unit containing the definition of
+  // the key function. This is unique if the key function is not inline.
+  // - Otherwise, the tables are emitted in every object that references any of
+  // them.
+  if (Module *M = RD->getOwningModule(); M && M->isNamedModule())
----------------
dwblaikie wrote:

The plumbing's already there though - and means one source of truth that both the consumer of the .pcm and the compilation of the .pcm->.o step use - rather than two separate pieces of code that also have to be kept in sync. (and the code's already there, the check before the one this patch proposes to be added to `isConsumerInterestedIn` is the modular code generation codepath already - and the populating of `ModularCodegenDecls` is part of that system)

I'd rather not add ad-hoc hardcoded things across these several places when we have a mechanism to use that gets set at .pcm time, is (sort of) generic across that for the usage and the implementation compilation.

It seems like fine existing infrastructure to further generalize to handle home-able types (that can be homed for code generation reasons, as well as for debug info reasons).

https://github.com/llvm/llvm-project/pull/75912