[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