[clang] [Clang][Sema] Expose static inline functions from GMF (PR #104701)
Jan Kokemüller via cfe-commits
cfe-commits at lists.llvm.org
Wed Aug 21 23:15:48 PDT 2024
================
@@ -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
More information about the cfe-commits
mailing list