The attrubite is applicable to functions and variables and changes the linkage of the subject to internal.
Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
Differential D13925
Implement __attribute__((internal_linkage)) eugenis on Oct 20 2015, 6:01 PM. Authored by
Details
The attrubite is applicable to functions and variables and changes the linkage of the subject to internal. Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
Diff Detail
Event Timeline
Comment Actions This new version supports attribute((internal_linkage)) on classes and even namespaces!
Comment Actions No diagnostic is issued for the following C test case: int x __attribute__((internal_linkage)); int x __attribute__((common)); int *f() { return &x; }
Comment Actions Thanks for noticing! Added missing attribute merging logic in SemaAttr.cpp.
Comment Actions Added a [[clang::internal_linkage]] spelling to the attribute.
Comment Actions I would like to hold off on adding the namespace attribute. There were persuasive reasons to not have attributes on namespaces that was discussed in EWG in Kona, and this is a feature we could add on later if there's sufficient design consensus.
Comment Actions Disabled the new attribute on namespaces.
Comment Actions I would like to see one more test, just to make sure that a Var subject doesn't also allow it on a parameter: void f(int a [[clang::internal_linkage]]); Aside from that, LGTM!
Comment Actions Hm, the current implementation allows all of the following: void f(int a [[clang::internal_linkage]]) { // 1 int b [[clang::internal_linkage]]; // 2 static int c [[clang::internal_linkage]]; // 3 } I'll fix (1). Is it OK to allow (2) and (3)? The attribute has no effect because the declarations already have internal linkage, so I'd say it behaves as documented. Comment Actions This is an interesting test case, though: inline int foo() { static int __attribute__((internal_linkage)) x; return x++; } If foo gets inlined, those call sites will use and update 'x'. If foo is not inlined, one definition of foo will win, and every caller will use its version of 'x'. We could emit a warning, but I kind of don't care. If you're using internal_linkage, you are operating outside the rules of C++. You're expecting multiple copies of these things to be emitted. Comment Actions How do I check if a Var is a local variable?
Comment Actions Added the new warning to a -W group.
Comment Actions LGTM, thank you!
|
Why doesn't this use Subjects ?