================
@@ -6926,11 +6926,26 @@ void Sema::AddOverloadCandidate(
/// have linkage. So that all entities of the same should share one
/// linkage. But in clang, different entities of the same could have
/// different linkage.
- NamedDecl *ND = Function;
- if (auto *SpecInfo = Function->getTemplateSpecializationInfo())
+ const NamedDecl *ND = Function;
+ bool IsImplicitlyInstantiated = false;
+ if (auto *SpecInfo = Function->getTemplateSpecializationInfo()) {
ND = SpecInfo->getTemplate();
-
- if (ND->getFormalLinkage() == Linkage::Internal) {
+ IsImplicitlyInstantiated = SpecInfo->getTemplateSpecializationKind() ==
+ TSK_ImplicitInstantiation;
+ }
+
+ /// Don't remove inline functions with internal linkage from the overload
+ /// set if they are declared in a GMF.
+ /// The global module is meant to be a transition mechanism for C and C++
+ /// headers.
+ /// Inline functions with internal linkage are a common pattern in headers
+ /// to avoid ODR issues.
----------------
jiixyj wrote:
Sounds like a good idea! One direction could be to create an additional
exception to [basic.link#17](<https://eel.is/c++draft/basic.link#17>) for
exposure of inline TU-local entities declared in a GMF, so that the program
would be no longer ill-formed in that case, right?
[depr.local](<https://eel.is/c++draft/depr.local>)'s note would have to be
changed to reflect this.
I will add to the comment that the proposed behavior violates basic.link#17.
https://github.com/llvm/llvm-project/pull/104701
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
