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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
