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

[Eric Fiselier via cfe-dev]

Sorry the namespace question was a bit of a distraction. I was curious
because I want to add a `__libcpp_internal` namespace that I can put
implementation details into without having to worry about them being
visible. However I don't want that to infect this discussion.

Evgenii thanks for all the work. I noticed that your tests rule out
applying the new attribute to a class declaration. However libc++ currently
applies the the visibility attributes to classes. I've always assumed that
this simply propagated the visibility to each member function but please
let me know if I'm wrong. I think this attribute needs to work the same way.

/Eric


On Tue, Oct 20, 2015 at 3:01 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com
> wrote:

> I've put together an implementation of this attribute:
> http://reviews.llvm.org/D13925
>
> On Tue, Oct 20, 2015 at 5: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.
> >
> > ~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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151020/a9b6fa9f/attachment.html>