[cfe-dev] [RFC] __attribute__((internal_linkage))

[Evgenii Stepanov via cfe-dev]

On Sun, Nov 1, 2015 at 4:42 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Tue, Oct 20, 2015 at 8:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> On Tue, Oct 20, 2015 at 8:52 PM, Evgenii Stepanov
>> <eugeni.stepanov at gmail.com> wrote:
>>> Do we really want to apply the attribute to the entire namespace? We'd
>>> need to skip at least extern template methods (like
>>> char_traits<char>).
>>
>> Eric was asking for it specifically, so I am assuming that was
>> something he might want to do. I would certainly be curious what the
>> semantics would be for it.
>>
>> I mostly would like to avoid replacing one solution that clutters
>> libc++ with another one that clutters equally, if we can avoid it.
>
> I've had some time to think on this a lot more lately, and I have some
> questions that may reverse my original opinion. What would the
> behavior be for something like this:
>
> namespace [[clang::internal_linkage]] n {
>   // Some decls...
> }
>
> namespace n {
>   // Other decls
> }
>
> Would it be an error if the namespace were re-opened without the
> attribute? What happens if the order of the namespace declarations
> were reversed? What if the namespaces were in separate TUs?

The current behavior is to apply internal linkage to "Some decls" but
not to "Other decls". I kinda like it.

...
namespace [[clang::internal_linkage]] n {
  // More decls...
}

And "More decls" are internal again.

>
> ~Aaron
>
>>
>> ~Aaron
>>
>>>
>>>
>>> On Tue, Oct 20, 2015 at 5:28 PM, Aaron Ballman <aaron.ballman at gmail.com> wrote:
>>>> On Fri, Oct 16, 2015 at 2:07 PM, Reid Kleckner <rnk at google.com> wrote:
>>>>> On Thu, Oct 15, 2015 at 6:55 PM, Eric Fiselier <eric at efcs.ca> wrote:
>>>>>>
>>>>>> 1. What would happen if the user attempts to take the address of a
>>>>>> function marked
>>>>>> `__attribute__((internal_linkage))`? Wouldn't this case required external
>>>>>> linkage?
>>>>>> For libc++ it's sufficient if it causes a compile error because users
>>>>>> aren't allowed
>>>>>> to take the address of functions in the standard library.
>>>>>
>>>>>
>>>>> Addresses of such functions would just compare not equal across TUs. I think
>>>>> that's pretty reasonable, and probably conformant. There are many ways that
>>>>> STL functions can be called indirectly (std::function's vtable), so I don't
>>>>> think we want to try to forbid that.
>>>>>
>>>>>>
>>>>>> 2. It would be great if we could apply the attribute to a namespace, that
>>>>>> in turn applies it to
>>>>>>    all of the symbols within. Would this be possible?
>>>>>
>>>>>
>>>>> The Clang attribute machinery *appears* to support attributes on namespace,
>>>>> but there doesn't seem to be a single test for it in the test suite. I don't
>>>>> think we can do that yet. Anyway, this feels like a separate feature request
>>>>> to me.
>>>>
>>>> C++ attributes are supported on namespaces, but I'm not certain about
>>>> GNU attributes on them. I'm not aware of any GNU attributes that
>>>> appertain to a namespace, so I'm not surprised about a lack of test
>>>> coverage.
>>>>
>>>> As for the feature itself, I think it's possibly a related feature
>>>> instead of a separate one, but I don't feel strongly. Given the use
>>>> case is "let's remove a bunch of not-really-working" libc++ code, I
>>>> can see the namespace being the better approach for those needs, with
>>>> a declaration attribute that happens to be the underlying
>>>> implementation of the namespace attribute.
>>>>
>>>> ~Aaron