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

[Aaron Ballman via cfe-dev]

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?

~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