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

[Chuanqi Xu via cfe-commits]

ChuanqiXu9 wrote:

> > @dmpolukhin I am still confusing about the problem. I mean, why your previous patch will break the reproducer and why this patch can "fix" it? I feel the current patch is somewhat workaround. It's not your fault. The original codes are somewhat tricky already. But let's try to find methods to fix it more fundamentally.
> 
> I understand why my previous patch broke Google's reproducer I attached to this PR. It happens because it deserializes eagerly lambda classes from the module that should be chosen as a pattern for template instantiation (function `CallbackUnaryHandler::RunHandler`). However code:
> 
> ```
>         if (auto *RD = dyn_cast<CXXRecordDecl>(FD->getLexicalParent()))
>           if (RD->isDependentContext() && !RD->isThisDeclarationADefinition())
>             continue;
> ```
> 
> skips setting body for the function so it cannot be used as the pattern and function body from different module is selected that now doesn't match the lambda. As I wrote in #109167 for captured variables to work correctly we need to make sure that enclosing function and lambda are coming from the same module. This code in some sense is doing similar thing, it forces canonical definition for the function defined inline within a class template to be from the same module as class template.
> 
> What I don't understand why clang cannot handle inline friend function coming from one module but class template coming from another module. It works in cases of member functions but friend inline function inside class template are special in this sense and template instantiation cannot deduce return type. I agree that my code is just reduces scope of previous hack to work only in cases when it is really required (we have test case). For the full solution I think we have two options: (1) figure out why inline friend function and template have to be from the same module, relax this requirement and remove this check completely or (2) make sure that canonical decls for class template, inline functions and potential lambdas are always chosen from the same module (my code from #109167 allows deserializing related decls from the same module if needed). I'm exploring option (1) at the moment but template instantiation code is not very familiar for me so it might take some time.

Thanks for the analysis. I feel (2) is easier to me IIUC. I feel it is a natural extension of your previous work. WDYT?

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