[clang] [C++20][Modules] Load function body from the module that gives canonical decl (PR #111992)

[Chuanqi Xu via cfe-commits]

================
@@ -10057,15 +10057,18 @@ void ASTReader::finishPendingActions() {
       // For a function defined inline within a class template, force the
       // canonical definition to be the one inside the canonical definition of
       // the template. This ensures that we instantiate from a correct view
-      // of the template.
+      // of the template. This behaviour seems to be important only for inline
+      // friend functions. For normal member functions, it might results in
+      // selecting canonical decl from module A but body from module B.
       //
       // Sadly we can't do this more generally: we can't be sure that all
       // copies of an arbitrary class definition will have the same members
       // defined (eg, some member functions may not be instantiated, and some
       // special members may or may not have been implicitly defined).
-      if (auto *RD = dyn_cast<CXXRecordDecl>(FD->getLexicalParent()))
-        if (RD->isDependentContext() && !RD->isThisDeclarationADefinition())
-          continue;
+      if (FD->getFriendObjectKind())
----------------
ChuanqiXu9 wrote:

Yeah let's try to understand the fundamental issue and fix it fundamentally.

> // >>> it looks like undocumented pragma?

This is the pragma for clang modules. I am not familiar with it too @ilya-biryukov is it possible to get some google forks familiar with this involved?

> // >>> What is the context of this code, is it GMF or part of module A, is it implicitly exported?

It is not GMF, nor a named module in C++20 sense nor exported in C++20 sense. It is a clang module. So the concept of `GMF`, named module and export ness (and the decl level) is not meaningful here.

> // >>> Seems like it was part of GMF

It won't be a GMF for sure.

> // >>> Why does it define something from module A !?

So given it is not the named module in C++20, so the ODR rule in C++20 doesn't apply here. Correct me if I am wrong. I feel clang modules implement the header's semantics, and the name of their modules are simply an annotation and doesn't have semantical effect. So I am not surprise that it is a valid code since it basically a concentration of two headers.

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