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

[Aaron Ballman via cfe-dev]

On Mon, Nov 2, 2015 at 4:29 PM, Evgenii Stepanov
<eugeni.stepanov at gmail.com> wrote:
> 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.

That behavior conflicts with how namespaces work in general. When you
open a namespace, you start adding declarations to it. When you reopen
the same namespace, you are adding declarations to the same namespace
as the original declarations. The behavior that you find useful is
something I would find confusing.

I don't have an issue with the non-namespace subjects for this
attribute, but I think we should be cautious about adding attributes
to namespaces; we can always add that feature later if it turns out to
be as desirable as I once thought it was. ;-)

~Aaron

>
>>
>> ~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