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