llvm dev - Jul 2016 - [cfe-dev] [RFC] __attribute__((internal_linkage))

Hi Evgenii,

I was wondering what the status is of your work to attach
"internal_linkage" to methods of standard library classes in libc++.
The
following piece of code doesn't link because a symbol (string::empty) is
undefined and it sounds like your work might fix the linkage error I'm
seeing.

$ cat test1.cpp
#include <string>
#include <functional>

int main() {
  using namespace std::placeholders;
  auto b = std::bind(&std::string::empty, _1);
}

On Mon, Nov 9, 2015 at 1:58 PM, Evgenii Stepanov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> In fact, during the code review we've decided against allowing this
> attribute on namespaces: http://reviews.llvEm.org/D13925
> <http://reviews.llvm.org/D13925>
>
> The intended use of this attribute in libc++ is on functions that
> programs are not allowed to take address of, like all methods of
> standard library classes. Visibility("hidden") attribute (which
we are
> replacing with internal_linkage) violates ODR the same way.
>
> Also, this attribute (for us) is not about locality or performance.
> Its primary purpose is to reliably exclude a class method from the
> export table. This is the way libc++ manages ABI stability: all class
> methods that are not part of the library ABI are defined in the
> headers with a set of attributes that ensure that they become internal
> to the translation unit. Always_inline does that in almost all cases,
> but almost is not good enough. Internal_linkage is a straighforward
> way to achieve the same.
>
>
> On Mon, Nov 9, 2015 at 1:34 PM, Martin J. O'Riordan
> <martin.oriordan at movidius.com> wrote:
> > With respect only to '__attribute__((internal_linkage))', not
'nodebug'
> and other parts of this topic; does hiding "some" members and not
others
> not introduce a violation of the ODR because some members of the class as
> it appears in one translation unit are not the same actual definitions as
> the apparently "same" members of the class in another translation
unit?  In
> particular the ODR requirement that would ensure that the address of a
> method was the same regardless of where the address was taken, including
> 'static' methods (no 'this' pointer)?  Or hidden things
like the guard
> variables for local static objects, default argument initialisers (which
> are instanced), etc.?
> >
> > I must admit that having spent years trying to lock down the
definition
> of the ODR, that this seems to fly in the opposite direction of the intent
> of that rule.
> >
> > I can (sort of) see why for particular reasons of locality you might
> want multiple actual definitions, even though they might exhibit the same
> behaviour, but maybe the answer for locality optimisation would be for the
> linker technology to evolve so that multiple copies of the same definition
> (sic) could be made; perhaps even at the Basic Block level [Block Level
> Linking].  But this too would lie under the auspices of the "as
if" rule
> and respect the ODR.
> >
> > There is something I am missing in this that is not making me at all
> comfortable about the use of this attribute for namespaces (apart from the
> reopening issues raised by others), and in particular the application to
> parts of a class but not the whole class.  I just feel that this is leading
> to semantic trouble.
> >
> > Thanks,
> >
> >         MartinO
> >
> > -----Original Message-----
> > From: Evgenii Stepanov [mailto:eugeni.stepanov at gmail.com]
> > Sent: 09 November 2015 18:49
> > To: Robinson, Paul <Paul_Robinson at playstation.sony.com>
> > Cc: Chris Lattner <clattner at apple.com>; sstewartgallus00 at
mylangara.bc.ca;
> llvm-dev at lists.llvm.org; Martin J. O'Riordan <martin.oriordan at
movidius.com
> >
> > Subject: Re: [llvm-dev] [cfe-dev] [RFC]
__attribute__((internal_linkage))
> >
> > Sorry, I totally missed updates to this thread.
> >
> > Anonymous namespace does not work for libc++ because we need to hide
> some class members, and export the rest. Namespace would hide all of them.
> AFAIK, "static" is un-deprecated in C++11 for multiple reasons,
including
> this one.
> >
> > I agree that nodebug should not affect codegen. It would also kill
debug
> info (ex. all debug locations in libc++ headers).
> >
> >
> > On Mon, Nov 2, 2015 at 11:57 AM, Robinson, Paul via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
> >>> Chris Lattner via llvm-dev
> >>> Sent: Saturday, October 31, 2015 2:58 PM
> >>> To: sstewartgallus00 at mylangara.bc.ca
> >>> Cc: LLVM Developers
> >>> Subject: Re: [llvm-dev] [cfe-dev] [RFC]
> >>> __attribute__((internal_linkage))
> >>>
> >>> Hi Stewart,
> >>>
> >>> I saw this get brought up at the LLVM devmtg in the context of
> >>> improving the stack size of libc++ frames.
> >>>
> >>> Have you guys considered a different approach to solving this
> >>> problem?  In the case of libc++, the _LIBCPP_INLINE_VISIBILITY
macro
> >>> currently expands out to "__attribute__
((__always_inline__))”.  It
> >>> seems reasonable to me to have it also add the “nodebug”
attribute as
> >>> well.  This should allow the allocas generated by inlining
lots of
> >>> frames to be promoted to registers (because there is no debug
info to
> pessimize).
> >>
> >> Are you suggesting that 'nodebug' should affect code
generation?
> >> It most definitely should not...
> >> --paulr
> >>
> >>>
> >>> This would dramatically shrink the stack frames of code using
libc++
> >>> at - O0, and would also make it go a lot faster.
> >>>
> >>> -Chris
> >>>
> >>>
> >>> > On Oct 29, 2015, at 6:35 AM, Martin J. O'Riordan via
llvm-dev
> >>> > <llvm-
> >>> dev at lists.llvm.org> wrote:
> >>> >
> >>> > I haven't been able to figure out from this thread
why this
> >>> > attribute is
> >>> necessary at all.
> >>> >
> >>> > Anonymous or unnamed namespaces were added to C++ for
this very
> >>> > purpose,
> >>> but the ISO C++ Standard does not discuss "linkage"
per-se because it
> >>> is outside the scope of the language specification.  But it
does
> >>> describes it in terms of having a hidden name which is
"unique" to
> >>> the translation unit, and under the "as if" rule,
internal linkage is
> >>> a common convention for achieving this.
> >>> >
> >>> > This is just Standardese for dealing with what compiler
> >>> > implementers
> >>> typically handle as "internal linkage" anyway; at
the same time, the
> >>> use of 'static' for this purpose was deprecated.  This
is
> >>> specifically stated in C++98 section 7.3.1.1 and unnamed
namespaces
> >>> are still similarly defined in C++17 (Working Paper) although
the
> >>> specific reference to the deprecation of 'static' for
this purpose is
> now gone.
> >>> >
> >>> > The closest the Standard gets to talking about linkage is
with
> >>> > Linkage
> >>> Specifications, and even here it tries to avoid to avoid
treading on
> >>> the definitions things like internal versus external linkage.
> >>> >
> >>> > So I am curious, what does this proposed attribute on
namespaces
> >>> > achieve
> >>> that cannot already be achieved with an anonymous or unnamed
namespace?
> >>> >
> >>> > Thanks,
> >>> >
> >>> >     Martin O'Riordan - Movidius Ltd.
> >>> >
> >>> > -----Original Message-----
> >>> > From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org]
On Behalf Of
> >>> Evgenii Stepanov via cfe-dev
> >>> > Sent: 23 October 2015 22:41
> >>> > To: Steven Stewart-Gallus <sstewartgallus00 at
mylangara.bc.ca>
> >>> > Cc: Clang Dev <cfe-dev at lists.llvm.org>
> >>> > Subject: Re: [cfe-dev] [RFC]
__attribute__((internal_linkage))
> >>> >
> >>> > Sounds right. The proposed attribute is a rough
equivalent of
> >>> >
> >>> > static void foo::do_method(void)
> >>> > {
> >>> >  // implementation here
> >>> > }
> >>> >
> >>> > where "static" does not mean a static class
member, but makes the
> >>> declaration local to the translation unit. C-style
"static".
> >>> >
> >>> > The patch in http://reviews.llvm.org/D13925 (waiting for
review,
> >>> > btw!)
> >>> supports this attribute on classes and namespaces, with this
syntax:
> >>> >
> >>> > namespace __attribute__((internal_linkage)) { }
> >>> >
> >>> >
> >>> > On Fri, Oct 23, 2015 at 9:03 AM, Steven Stewart-Gallus
via cfe-dev
> >>> > <cfe-
> >>> dev at lists.llvm.org> wrote:
> >>> >> Hello,
> >>> >>
> >>> >> Can I ask for some clarification?
> >>> >>
> >>> >> Apparently, C++ doesn't allow to static class
methods?
> >>> >>
> >>> >> While in C one might write inside a header file:
> >>> >>
> >>> >> static inline void mylib_foo_do_method(struct
mylib_foo *foo) {
> >>> >>   // implementation here
> >>> >> }
> >>> >>
> >>> >> In C++ the typical style would be to write something
like:
> >>> >>
> >>> >> namespace mylib {
> >>> >>
> >>> >> void foo::do_method(void)
> >>> >> {
> >>> >>  // implementation here
> >>> >> }
> >>> >> }
> >>> >>
> >>> >> Unfortunately, the C++ case then implies some linkage
behaviour
> >>> >> that some might not want.
> >>> >>
> >>> >> Apparently, one can't do things like:
> >>> >>
> >>> >> namespace mylib {
> >>> >>
> >>> >> static void foo::do_method(void)
> >>> >> {
> >>> >>  // implementation here
> >>> >> }
> >>> >> }
> >>> >>
> >>> >> Or,
> >>> >>
> >>> >> namespace {
> >>> >> namespace mylib {
> >>> >>
> >>> >> static void foo::do_method(void)
> >>> >> {
> >>> >>  // implementation here
> >>> >> }
> >>> >> }
> >>> >> }
> >>> >>
> >>> >> Also, if you wanted to an attribute to a whole
namespace you
> >>> >> should do something like the following I think:
> >>> >>
> >>> >> namespace mylib {
> >>> >> [[clang::internal_linkage]];
> >>> >>
> >>> >> static void foo::do_method(void)
> >>> >> {
> >>> >>  // implementation here
> >>> >> }
> >>> >> }
> >>> >>
> >>> >>
> >>> >> Thank you,
> >>> >> Steven Stewart-Gallus
> >>> >> _______________________________________________
> >>> >> cfe-dev mailing list
> >>> >> cfe-dev at lists.llvm.org
> >>> >>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>> > _______________________________________________
> >>> > cfe-dev mailing list
> >>> > cfe-dev at lists.llvm.org
> >>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>> >
> >>> > _______________________________________________
> >>> > LLVM Developers mailing list
> >>> > llvm-dev at lists.llvm.org
> >>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160712/9f3da880/attachment.html>

Hi,

it's been put on hold for other higher priority work. I still want to
get it done one day, but it's not clear when that would be.

On Tue, Jul 12, 2016 at 6:11 PM, Akira Hatanaka <ahatanak at gmail.com>
wrote:
> Hi Evgenii,
>
> I was wondering what the status is of your work to attach
"internal_linkage"
> to methods of standard library classes in libc++. The following piece of
> code doesn't link because a symbol (string::empty) is undefined and it
> sounds like your work might fix the linkage error I'm seeing.
>
> $ cat test1.cpp
> #include <string>
> #include <functional>
>
> int main() {
>   using namespace std::placeholders;
>   auto b = std::bind(&std::string::empty, _1);
> }
>
> On Mon, Nov 9, 2015 at 1:58 PM, Evgenii Stepanov via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> In fact, during the code review we've decided against allowing this
>> attribute on namespaces: http://reviews.llvEm.org/D13925
>>
>>
>> The intended use of this attribute in libc++ is on functions that
>> programs are not allowed to take address of, like all methods of
>> standard library classes. Visibility("hidden") attribute
(which we are
>> replacing with internal_linkage) violates ODR the same way.
>>
>> Also, this attribute (for us) is not about locality or performance.
>> Its primary purpose is to reliably exclude a class method from the
>> export table. This is the way libc++ manages ABI stability: all class
>> methods that are not part of the library ABI are defined in the
>> headers with a set of attributes that ensure that they become internal
>> to the translation unit. Always_inline does that in almost all cases,
>> but almost is not good enough. Internal_linkage is a straighforward
>> way to achieve the same.
>>
>>
>> On Mon, Nov 9, 2015 at 1:34 PM, Martin J. O'Riordan
>> <martin.oriordan at movidius.com> wrote:
>> > With respect only to '__attribute__((internal_linkage))',
not 'nodebug'
>> > and other parts of this topic; does hiding "some"
members and not others not
>> > introduce a violation of the ODR because some members of the class
as it
>> > appears in one translation unit are not the same actual
definitions as the
>> > apparently "same" members of the class in another
translation unit?  In
>> > particular the ODR requirement that would ensure that the address
of a
>> > method was the same regardless of where the address was taken,
including
>> > 'static' methods (no 'this' pointer)?  Or hidden
things like the guard
>> > variables for local static objects, default argument initialisers
(which are
>> > instanced), etc.?
>> >
>> > I must admit that having spent years trying to lock down the
definition
>> > of the ODR, that this seems to fly in the opposite direction of
the intent
>> > of that rule.
>> >
>> > I can (sort of) see why for particular reasons of locality you
might
>> > want multiple actual definitions, even though they might exhibit
the same
>> > behaviour, but maybe the answer for locality optimisation would be
for the
>> > linker technology to evolve so that multiple copies of the same
definition
>> > (sic) could be made; perhaps even at the Basic Block level [Block
Level
>> > Linking].  But this too would lie under the auspices of the
"as if" rule and
>> > respect the ODR.
>> >
>> > There is something I am missing in this that is not making me at
all
>> > comfortable about the use of this attribute for namespaces (apart
from the
>> > reopening issues raised by others), and in particular the
application to
>> > parts of a class but not the whole class.  I just feel that this
is leading
>> > to semantic trouble.
>> >
>> > Thanks,
>> >
>> >         MartinO
>> >
>> > -----Original Message-----
>> > From: Evgenii Stepanov [mailto:eugeni.stepanov at gmail.com]
>> > Sent: 09 November 2015 18:49
>> > To: Robinson, Paul <Paul_Robinson at playstation.sony.com>
>> > Cc: Chris Lattner <clattner at apple.com>;
>> > sstewartgallus00 at mylangara.bc.ca; llvm-dev at lists.llvm.org;
Martin J.
>> > O'Riordan <martin.oriordan at movidius.com>
>> > Subject: Re: [llvm-dev] [cfe-dev] [RFC]
>> > __attribute__((internal_linkage))
>> >
>> > Sorry, I totally missed updates to this thread.
>> >
>> > Anonymous namespace does not work for libc++ because we need to
hide
>> > some class members, and export the rest. Namespace would hide all
of them.
>> > AFAIK, "static" is un-deprecated in C++11 for multiple
reasons, including
>> > this one.
>> >
>> > I agree that nodebug should not affect codegen. It would also kill
debug
>> > info (ex. all debug locations in libc++ headers).
>> >
>> >
>> > On Mon, Nov 2, 2015 at 11:57 AM, Robinson, Paul via llvm-dev
>> > <llvm-dev at lists.llvm.org> wrote:
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org]
On Behalf Of
>> >>> Chris Lattner via llvm-dev
>> >>> Sent: Saturday, October 31, 2015 2:58 PM
>> >>> To: sstewartgallus00 at mylangara.bc.ca
>> >>> Cc: LLVM Developers
>> >>> Subject: Re: [llvm-dev] [cfe-dev] [RFC]
>> >>> __attribute__((internal_linkage))
>> >>>
>> >>> Hi Stewart,
>> >>>
>> >>> I saw this get brought up at the LLVM devmtg in the
context of
>> >>> improving the stack size of libc++ frames.
>> >>>
>> >>> Have you guys considered a different approach to solving
this
>> >>> problem?  In the case of libc++, the
_LIBCPP_INLINE_VISIBILITY macro
>> >>> currently expands out to "__attribute__
((__always_inline__))”.  It
>> >>> seems reasonable to me to have it also add the “nodebug”
attribute as
>> >>> well.  This should allow the allocas generated by inlining
lots of
>> >>> frames to be promoted to registers (because there is no
debug info to
>> >>> pessimize).
>> >>
>> >> Are you suggesting that 'nodebug' should affect code
generation?
>> >> It most definitely should not...
>> >> --paulr
>> >>
>> >>>
>> >>> This would dramatically shrink the stack frames of code
using libc++
>> >>> at - O0, and would also make it go a lot faster.
>> >>>
>> >>> -Chris
>> >>>
>> >>>
>> >>> > On Oct 29, 2015, at 6:35 AM, Martin J. O'Riordan
via llvm-dev
>> >>> > <llvm-
>> >>> dev at lists.llvm.org> wrote:
>> >>> >
>> >>> > I haven't been able to figure out from this
thread why this
>> >>> > attribute is
>> >>> necessary at all.
>> >>> >
>> >>> > Anonymous or unnamed namespaces were added to C++ for
this very
>> >>> > purpose,
>> >>> but the ISO C++ Standard does not discuss
"linkage" per-se because it
>> >>> is outside the scope of the language specification.  But
it does
>> >>> describes it in terms of having a hidden name which is
"unique" to
>> >>> the translation unit, and under the "as if"
rule, internal linkage is
>> >>> a common convention for achieving this.
>> >>> >
>> >>> > This is just Standardese for dealing with what
compiler
>> >>> > implementers
>> >>> typically handle as "internal linkage" anyway;
at the same time, the
>> >>> use of 'static' for this purpose was deprecated. 
This is
>> >>> specifically stated in C++98 section 7.3.1.1 and unnamed
namespaces
>> >>> are still similarly defined in C++17 (Working Paper)
although the
>> >>> specific reference to the deprecation of 'static'
for this purpose is
>> >>> now gone.
>> >>> >
>> >>> > The closest the Standard gets to talking about
linkage is with
>> >>> > Linkage
>> >>> Specifications, and even here it tries to avoid to avoid
treading on
>> >>> the definitions things like internal versus external
linkage.
>> >>> >
>> >>> > So I am curious, what does this proposed attribute on
namespaces
>> >>> > achieve
>> >>> that cannot already be achieved with an anonymous or
unnamed
>> >>> namespace?
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> >     Martin O'Riordan - Movidius Ltd.
>> >>> >
>> >>> > -----Original Message-----
>> >>> > From: cfe-dev [mailto:cfe-dev-bounces at
lists.llvm.org] On Behalf Of
>> >>> Evgenii Stepanov via cfe-dev
>> >>> > Sent: 23 October 2015 22:41
>> >>> > To: Steven Stewart-Gallus <sstewartgallus00 at
mylangara.bc.ca>
>> >>> > Cc: Clang Dev <cfe-dev at lists.llvm.org>
>> >>> > Subject: Re: [cfe-dev] [RFC]
__attribute__((internal_linkage))
>> >>> >
>> >>> > Sounds right. The proposed attribute is a rough
equivalent of
>> >>> >
>> >>> > static void foo::do_method(void)
>> >>> > {
>> >>> >  // implementation here
>> >>> > }
>> >>> >
>> >>> > where "static" does not mean a static class
member, but makes the
>> >>> declaration local to the translation unit. C-style
"static".
>> >>> >
>> >>> > The patch in http://reviews.llvm.org/D13925 (waiting
for review,
>> >>> > btw!)
>> >>> supports this attribute on classes and namespaces, with
this syntax:
>> >>> >
>> >>> > namespace __attribute__((internal_linkage)) { }
>> >>> >
>> >>> >
>> >>> > On Fri, Oct 23, 2015 at 9:03 AM, Steven
Stewart-Gallus via cfe-dev
>> >>> > <cfe-
>> >>> dev at lists.llvm.org> wrote:
>> >>> >> Hello,
>> >>> >>
>> >>> >> Can I ask for some clarification?
>> >>> >>
>> >>> >> Apparently, C++ doesn't allow to static class
methods?
>> >>> >>
>> >>> >> While in C one might write inside a header file:
>> >>> >>
>> >>> >> static inline void mylib_foo_do_method(struct
mylib_foo *foo) {
>> >>> >>   // implementation here
>> >>> >> }
>> >>> >>
>> >>> >> In C++ the typical style would be to write
something like:
>> >>> >>
>> >>> >> namespace mylib {
>> >>> >>
>> >>> >> void foo::do_method(void)
>> >>> >> {
>> >>> >>  // implementation here
>> >>> >> }
>> >>> >> }
>> >>> >>
>> >>> >> Unfortunately, the C++ case then implies some
linkage behaviour
>> >>> >> that some might not want.
>> >>> >>
>> >>> >> Apparently, one can't do things like:
>> >>> >>
>> >>> >> namespace mylib {
>> >>> >>
>> >>> >> static void foo::do_method(void)
>> >>> >> {
>> >>> >>  // implementation here
>> >>> >> }
>> >>> >> }
>> >>> >>
>> >>> >> Or,
>> >>> >>
>> >>> >> namespace {
>> >>> >> namespace mylib {
>> >>> >>
>> >>> >> static void foo::do_method(void)
>> >>> >> {
>> >>> >>  // implementation here
>> >>> >> }
>> >>> >> }
>> >>> >> }
>> >>> >>
>> >>> >> Also, if you wanted to an attribute to a whole
namespace you
>> >>> >> should do something like the following I think:
>> >>> >>
>> >>> >> namespace mylib {
>> >>> >> [[clang::internal_linkage]];
>> >>> >>
>> >>> >> static void foo::do_method(void)
>> >>> >> {
>> >>> >>  // implementation here
>> >>> >> }
>> >>> >> }
>> >>> >>
>> >>> >>
>> >>> >> Thank you,
>> >>> >> Steven Stewart-Gallus
>> >>> >> _______________________________________________
>> >>> >> cfe-dev mailing list
>> >>> >> cfe-dev at lists.llvm.org
>> >>> >>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >>> > _______________________________________________
>> >>> > cfe-dev mailing list
>> >>> > cfe-dev at lists.llvm.org
>> >>> >
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >>> >
>> >>> > _______________________________________________
>> >>> > LLVM Developers mailing list
>> >>> > llvm-dev at lists.llvm.org
>> >>> >
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>
>> >>> _______________________________________________
>> >>> LLVM Developers mailing list
>> >>> llvm-dev at lists.llvm.org
>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

OK, thanks.

One more question: which part of the standard says you aren't allowed to
take the addresses of methods of classes in the standard library?

On Tue, Jul 12, 2016 at 6:16 PM, Evgenii Stepanov <eugeni.stepanov at
gmail.com
> wrote:
> Hi,
>
> it's been put on hold for other higher priority work. I still want to
> get it done one day, but it's not clear when that would be.
>
> On Tue, Jul 12, 2016 at 6:11 PM, Akira Hatanaka <ahatanak at
gmail.com>
> wrote:
> > Hi Evgenii,
> >
> > I was wondering what the status is of your work to attach
> "internal_linkage"
> > to methods of standard library classes in libc++. The following piece
of
> > code doesn't link because a symbol (string::empty) is undefined
and it
> > sounds like your work might fix the linkage error I'm seeing.
> >
> > $ cat test1.cpp
> > #include <string>
> > #include <functional>
> >
> > int main() {
> >   using namespace std::placeholders;
> >   auto b = std::bind(&std::string::empty, _1);
> > }
> >
> > On Mon, Nov 9, 2015 at 1:58 PM, Evgenii Stepanov via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>
> >> In fact, during the code review we've decided against allowing
this
> >> attribute on namespaces: http://reviews.llvEm.org/D13925
> >>
> >>
> >> The intended use of this attribute in libc++ is on functions that
> >> programs are not allowed to take address of, like all methods of
> >> standard library classes. Visibility("hidden") attribute
(which we are
> >> replacing with internal_linkage) violates ODR the same way.
> >>
> >> Also, this attribute (for us) is not about locality or
performance.
> >> Its primary purpose is to reliably exclude a class method from the
> >> export table. This is the way libc++ manages ABI stability: all
class
> >> methods that are not part of the library ABI are defined in the
> >> headers with a set of attributes that ensure that they become
internal
> >> to the translation unit. Always_inline does that in almost all
cases,
> >> but almost is not good enough. Internal_linkage is a
straighforward
> >> way to achieve the same.
> >>
> >>
> >> On Mon, Nov 9, 2015 at 1:34 PM, Martin J. O'Riordan
> >> <martin.oriordan at movidius.com> wrote:
> >> > With respect only to
'__attribute__((internal_linkage))', not
> 'nodebug'
> >> > and other parts of this topic; does hiding "some"
members and not
> others not
> >> > introduce a violation of the ODR because some members of the
class as
> it
> >> > appears in one translation unit are not the same actual
definitions
> as the
> >> > apparently "same" members of the class in another
translation unit?
> In
> >> > particular the ODR requirement that would ensure that the
address of a
> >> > method was the same regardless of where the address was
taken,
> including
> >> > 'static' methods (no 'this' pointer)?  Or
hidden things like the guard
> >> > variables for local static objects, default argument
initialisers
> (which are
> >> > instanced), etc.?
> >> >
> >> > I must admit that having spent years trying to lock down the
> definition
> >> > of the ODR, that this seems to fly in the opposite direction
of the
> intent
> >> > of that rule.
> >> >
> >> > I can (sort of) see why for particular reasons of locality
you might
> >> > want multiple actual definitions, even though they might
exhibit the
> same
> >> > behaviour, but maybe the answer for locality optimisation
would be
> for the
> >> > linker technology to evolve so that multiple copies of the
same
> definition
> >> > (sic) could be made; perhaps even at the Basic Block level
[Block
> Level
> >> > Linking].  But this too would lie under the auspices of the
"as if"
> rule and
> >> > respect the ODR.
> >> >
> >> > There is something I am missing in this that is not making me
at all
> >> > comfortable about the use of this attribute for namespaces
(apart
> from the
> >> > reopening issues raised by others), and in particular the
application
> to
> >> > parts of a class but not the whole class.  I just feel that
this is
> leading
> >> > to semantic trouble.
> >> >
> >> > Thanks,
> >> >
> >> >         MartinO
> >> >
> >> > -----Original Message-----
> >> > From: Evgenii Stepanov [mailto:eugeni.stepanov at gmail.com]
> >> > Sent: 09 November 2015 18:49
> >> > To: Robinson, Paul <Paul_Robinson at
playstation.sony.com>
> >> > Cc: Chris Lattner <clattner at apple.com>;
> >> > sstewartgallus00 at mylangara.bc.ca; llvm-dev at
lists.llvm.org; Martin J.
> >> > O'Riordan <martin.oriordan at movidius.com>
> >> > Subject: Re: [llvm-dev] [cfe-dev] [RFC]
> >> > __attribute__((internal_linkage))
> >> >
> >> > Sorry, I totally missed updates to this thread.
> >> >
> >> > Anonymous namespace does not work for libc++ because we need
to hide
> >> > some class members, and export the rest. Namespace would hide
all of
> them.
> >> > AFAIK, "static" is un-deprecated in C++11 for
multiple reasons,
> including
> >> > this one.
> >> >
> >> > I agree that nodebug should not affect codegen. It would also
kill
> debug
> >> > info (ex. all debug locations in libc++ headers).
> >> >
> >> >
> >> > On Mon, Nov 2, 2015 at 11:57 AM, Robinson, Paul via llvm-dev
> >> > <llvm-dev at lists.llvm.org> wrote:
> >> >>
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: llvm-dev [mailto:llvm-dev-bounces at
lists.llvm.org] On Behalf
> Of
> >> >>> Chris Lattner via llvm-dev
> >> >>> Sent: Saturday, October 31, 2015 2:58 PM
> >> >>> To: sstewartgallus00 at mylangara.bc.ca
> >> >>> Cc: LLVM Developers
> >> >>> Subject: Re: [llvm-dev] [cfe-dev] [RFC]
> >> >>> __attribute__((internal_linkage))
> >> >>>
> >> >>> Hi Stewart,
> >> >>>
> >> >>> I saw this get brought up at the LLVM devmtg in the
context of
> >> >>> improving the stack size of libc++ frames.
> >> >>>
> >> >>> Have you guys considered a different approach to
solving this
> >> >>> problem?  In the case of libc++, the
_LIBCPP_INLINE_VISIBILITY macro
> >> >>> currently expands out to "__attribute__
((__always_inline__))”.  It
> >> >>> seems reasonable to me to have it also add the
“nodebug” attribute
> as
> >> >>> well.  This should allow the allocas generated by
inlining lots of
> >> >>> frames to be promoted to registers (because there is
no debug info
> to
> >> >>> pessimize).
> >> >>
> >> >> Are you suggesting that 'nodebug' should affect
code generation?
> >> >> It most definitely should not...
> >> >> --paulr
> >> >>
> >> >>>
> >> >>> This would dramatically shrink the stack frames of
code using libc++
> >> >>> at - O0, and would also make it go a lot faster.
> >> >>>
> >> >>> -Chris
> >> >>>
> >> >>>
> >> >>> > On Oct 29, 2015, at 6:35 AM, Martin J.
O'Riordan via llvm-dev
> >> >>> > <llvm-
> >> >>> dev at lists.llvm.org> wrote:
> >> >>> >
> >> >>> > I haven't been able to figure out from this
thread why this
> >> >>> > attribute is
> >> >>> necessary at all.
> >> >>> >
> >> >>> > Anonymous or unnamed namespaces were added to
C++ for this very
> >> >>> > purpose,
> >> >>> but the ISO C++ Standard does not discuss
"linkage" per-se because
> it
> >> >>> is outside the scope of the language specification. 
But it does
> >> >>> describes it in terms of having a hidden name which
is "unique" to
> >> >>> the translation unit, and under the "as if"
rule, internal linkage
> is
> >> >>> a common convention for achieving this.
> >> >>> >
> >> >>> > This is just Standardese for dealing with what
compiler
> >> >>> > implementers
> >> >>> typically handle as "internal linkage"
anyway; at the same time, the
> >> >>> use of 'static' for this purpose was
deprecated.  This is
> >> >>> specifically stated in C++98 section 7.3.1.1 and
unnamed namespaces
> >> >>> are still similarly defined in C++17 (Working Paper)
although the
> >> >>> specific reference to the deprecation of
'static' for this purpose
> is
> >> >>> now gone.
> >> >>> >
> >> >>> > The closest the Standard gets to talking about
linkage is with
> >> >>> > Linkage
> >> >>> Specifications, and even here it tries to avoid to
avoid treading on
> >> >>> the definitions things like internal versus external
linkage.
> >> >>> >
> >> >>> > So I am curious, what does this proposed
attribute on namespaces
> >> >>> > achieve
> >> >>> that cannot already be achieved with an anonymous or
unnamed
> >> >>> namespace?
> >> >>> >
> >> >>> > Thanks,
> >> >>> >
> >> >>> >     Martin O'Riordan - Movidius Ltd.
> >> >>> >
> >> >>> > -----Original Message-----
> >> >>> > From: cfe-dev [mailto:cfe-dev-bounces at
lists.llvm.org] On Behalf
> Of
> >> >>> Evgenii Stepanov via cfe-dev
> >> >>> > Sent: 23 October 2015 22:41
> >> >>> > To: Steven Stewart-Gallus <sstewartgallus00
at mylangara.bc.ca>
> >> >>> > Cc: Clang Dev <cfe-dev at lists.llvm.org>
> >> >>> > Subject: Re: [cfe-dev] [RFC]
__attribute__((internal_linkage))
> >> >>> >
> >> >>> > Sounds right. The proposed attribute is a rough
equivalent of
> >> >>> >
> >> >>> > static void foo::do_method(void)
> >> >>> > {
> >> >>> >  // implementation here
> >> >>> > }
> >> >>> >
> >> >>> > where "static" does not mean a static
class member, but makes the
> >> >>> declaration local to the translation unit. C-style
"static".
> >> >>> >
> >> >>> > The patch in http://reviews.llvm.org/D13925
(waiting for review,
> >> >>> > btw!)
> >> >>> supports this attribute on classes and namespaces,
with this syntax:
> >> >>> >
> >> >>> > namespace __attribute__((internal_linkage)) { }
> >> >>> >
> >> >>> >
> >> >>> > On Fri, Oct 23, 2015 at 9:03 AM, Steven
Stewart-Gallus via cfe-dev
> >> >>> > <cfe-
> >> >>> dev at lists.llvm.org> wrote:
> >> >>> >> Hello,
> >> >>> >>
> >> >>> >> Can I ask for some clarification?
> >> >>> >>
> >> >>> >> Apparently, C++ doesn't allow to static
class methods?
> >> >>> >>
> >> >>> >> While in C one might write inside a header
file:
> >> >>> >>
> >> >>> >> static inline void
mylib_foo_do_method(struct mylib_foo *foo) {
> >> >>> >>   // implementation here
> >> >>> >> }
> >> >>> >>
> >> >>> >> In C++ the typical style would be to write
something like:
> >> >>> >>
> >> >>> >> namespace mylib {
> >> >>> >>
> >> >>> >> void foo::do_method(void)
> >> >>> >> {
> >> >>> >>  // implementation here
> >> >>> >> }
> >> >>> >> }
> >> >>> >>
> >> >>> >> Unfortunately, the C++ case then implies
some linkage behaviour
> >> >>> >> that some might not want.
> >> >>> >>
> >> >>> >> Apparently, one can't do things like:
> >> >>> >>
> >> >>> >> namespace mylib {
> >> >>> >>
> >> >>> >> static void foo::do_method(void)
> >> >>> >> {
> >> >>> >>  // implementation here
> >> >>> >> }
> >> >>> >> }
> >> >>> >>
> >> >>> >> Or,
> >> >>> >>
> >> >>> >> namespace {
> >> >>> >> namespace mylib {
> >> >>> >>
> >> >>> >> static void foo::do_method(void)
> >> >>> >> {
> >> >>> >>  // implementation here
> >> >>> >> }
> >> >>> >> }
> >> >>> >> }
> >> >>> >>
> >> >>> >> Also, if you wanted to an attribute to a
whole namespace you
> >> >>> >> should do something like the following I
think:
> >> >>> >>
> >> >>> >> namespace mylib {
> >> >>> >> [[clang::internal_linkage]];
> >> >>> >>
> >> >>> >> static void foo::do_method(void)
> >> >>> >> {
> >> >>> >>  // implementation here
> >> >>> >> }
> >> >>> >> }
> >> >>> >>
> >> >>> >>
> >> >>> >> Thank you,
> >> >>> >> Steven Stewart-Gallus
> >> >>> >>
_______________________________________________
> >> >>> >> cfe-dev mailing list
> >> >>> >> cfe-dev at lists.llvm.org
> >> >>> >>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >> >>> > _______________________________________________
> >> >>> > cfe-dev mailing list
> >> >>> > cfe-dev at lists.llvm.org
> >> >>> >
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >> >>> >
> >> >>> > _______________________________________________
> >> >>> > LLVM Developers mailing list
> >> >>> > llvm-dev at lists.llvm.org
> >> >>> >
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> >>>
> >> >>> _______________________________________________
> >> >>> LLVM Developers mailing list
> >> >>> llvm-dev at lists.llvm.org
> >> >>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> >> _______________________________________________
> >> >> LLVM Developers mailing list
> >> >> llvm-dev at lists.llvm.org
> >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> >
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160712/729b9f97/attachment-0001.html>

Hi Evgenii,

I have one question about this (planned) change: what if a function is not
inlined? The linker will not ODR merge them with this change, which isn’t great.

What makes “internal” linkage more desirable than "linkonce_odr +
visibility hidden"?

— 
Mehdi

> On Jul 12, 2016, at 6:16 PM, Evgenii Stepanov via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi,
> 
> it's been put on hold for other higher priority work. I still want to
> get it done one day, but it's not clear when that would be.
> 
> On Tue, Jul 12, 2016 at 6:11 PM, Akira Hatanaka <ahatanak at
gmail.com> wrote:
>> Hi Evgenii,
>> 
>> I was wondering what the status is of your work to attach
"internal_linkage"
>> to methods of standard library classes in libc++. The following piece
of
>> code doesn't link because a symbol (string::empty) is undefined and
it
>> sounds like your work might fix the linkage error I'm seeing.
>> 
>> $ cat test1.cpp
>> #include <string>
>> #include <functional>
>> 
>> int main() {
>>  using namespace std::placeholders;
>>  auto b = std::bind(&std::string::empty, _1);
>> }
>> 
>> On Mon, Nov 9, 2015 at 1:58 PM, Evgenii Stepanov via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> In fact, during the code review we've decided against allowing
this
>>> attribute on namespaces: http://reviews.llvEm.org/D13925
>>> 
>>> 
>>> The intended use of this attribute in libc++ is on functions that
>>> programs are not allowed to take address of, like all methods of
>>> standard library classes. Visibility("hidden") attribute
(which we are
>>> replacing with internal_linkage) violates ODR the same way.
>>> 
>>> Also, this attribute (for us) is not about locality or performance.
>>> Its primary purpose is to reliably exclude a class method from the
>>> export table. This is the way libc++ manages ABI stability: all
class
>>> methods that are not part of the library ABI are defined in the
>>> headers with a set of attributes that ensure that they become
internal
>>> to the translation unit. Always_inline does that in almost all
cases,
>>> but almost is not good enough. Internal_linkage is a straighforward
>>> way to achieve the same.
>>> 
>>> 
>>> On Mon, Nov 9, 2015 at 1:34 PM, Martin J. O'Riordan
>>> <martin.oriordan at movidius.com> wrote:
>>>> With respect only to
'__attribute__((internal_linkage))', not 'nodebug'
>>>> and other parts of this topic; does hiding "some"
members and not others not
>>>> introduce a violation of the ODR because some members of the
class as it
>>>> appears in one translation unit are not the same actual
definitions as the
>>>> apparently "same" members of the class in another
translation unit?  In
>>>> particular the ODR requirement that would ensure that the
address of a
>>>> method was the same regardless of where the address was taken,
including
>>>> 'static' methods (no 'this' pointer)?  Or
hidden things like the guard
>>>> variables for local static objects, default argument
initialisers (which are
>>>> instanced), etc.?
>>>> 
>>>> I must admit that having spent years trying to lock down the
definition
>>>> of the ODR, that this seems to fly in the opposite direction of
the intent
>>>> of that rule.
>>>> 
>>>> I can (sort of) see why for particular reasons of locality you
might
>>>> want multiple actual definitions, even though they might
exhibit the same
>>>> behaviour, but maybe the answer for locality optimisation would
be for the
>>>> linker technology to evolve so that multiple copies of the same
definition
>>>> (sic) could be made; perhaps even at the Basic Block level
[Block Level
>>>> Linking].  But this too would lie under the auspices of the
"as if" rule and
>>>> respect the ODR.
>>>> 
>>>> There is something I am missing in this that is not making me
at all
>>>> comfortable about the use of this attribute for namespaces
(apart from the
>>>> reopening issues raised by others), and in particular the
application to
>>>> parts of a class but not the whole class.  I just feel that
this is leading
>>>> to semantic trouble.
>>>> 
>>>> Thanks,
>>>> 
>>>>        MartinO
>>>> 
>>>> -----Original Message-----
>>>> From: Evgenii Stepanov [mailto:eugeni.stepanov at gmail.com]
>>>> Sent: 09 November 2015 18:49
>>>> To: Robinson, Paul <Paul_Robinson at
playstation.sony.com>
>>>> Cc: Chris Lattner <clattner at apple.com>;
>>>> sstewartgallus00 at mylangara.bc.ca; llvm-dev at
lists.llvm.org; Martin J.
>>>> O'Riordan <martin.oriordan at movidius.com>
>>>> Subject: Re: [llvm-dev] [cfe-dev] [RFC]
>>>> __attribute__((internal_linkage))
>>>> 
>>>> Sorry, I totally missed updates to this thread.
>>>> 
>>>> Anonymous namespace does not work for libc++ because we need to
hide
>>>> some class members, and export the rest. Namespace would hide
all of them.
>>>> AFAIK, "static" is un-deprecated in C++11 for
multiple reasons, including
>>>> this one.
>>>> 
>>>> I agree that nodebug should not affect codegen. It would also
kill debug
>>>> info (ex. all debug locations in libc++ headers).
>>>> 
>>>> 
>>>> On Mon, Nov 2, 2015 at 11:57 AM, Robinson, Paul via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: llvm-dev [mailto:llvm-dev-bounces at
lists.llvm.org] On Behalf Of
>>>>>> Chris Lattner via llvm-dev
>>>>>> Sent: Saturday, October 31, 2015 2:58 PM
>>>>>> To: sstewartgallus00 at mylangara.bc.ca
>>>>>> Cc: LLVM Developers
>>>>>> Subject: Re: [llvm-dev] [cfe-dev] [RFC]
>>>>>> __attribute__((internal_linkage))
>>>>>> 
>>>>>> Hi Stewart,
>>>>>> 
>>>>>> I saw this get brought up at the LLVM devmtg in the
context of
>>>>>> improving the stack size of libc++ frames.
>>>>>> 
>>>>>> Have you guys considered a different approach to
solving this
>>>>>> problem?  In the case of libc++, the
_LIBCPP_INLINE_VISIBILITY macro
>>>>>> currently expands out to "__attribute__
((__always_inline__))”.  It
>>>>>> seems reasonable to me to have it also add the
“nodebug” attribute as
>>>>>> well.  This should allow the allocas generated by
inlining lots of
>>>>>> frames to be promoted to registers (because there is no
debug info to
>>>>>> pessimize).
>>>>> 
>>>>> Are you suggesting that 'nodebug' should affect
code generation?
>>>>> It most definitely should not...
>>>>> --paulr
>>>>> 
>>>>>> 
>>>>>> This would dramatically shrink the stack frames of code
using libc++
>>>>>> at - O0, and would also make it go a lot faster.
>>>>>> 
>>>>>> -Chris
>>>>>> 
>>>>>> 
>>>>>>> On Oct 29, 2015, at 6:35 AM, Martin J.
O'Riordan via llvm-dev
>>>>>>> <llvm-
>>>>>> dev at lists.llvm.org> wrote:
>>>>>>> 
>>>>>>> I haven't been able to figure out from this
thread why this
>>>>>>> attribute is
>>>>>> necessary at all.
>>>>>>> 
>>>>>>> Anonymous or unnamed namespaces were added to C++
for this very
>>>>>>> purpose,
>>>>>> but the ISO C++ Standard does not discuss
"linkage" per-se because it
>>>>>> is outside the scope of the language specification. 
But it does
>>>>>> describes it in terms of having a hidden name which is
"unique" to
>>>>>> the translation unit, and under the "as if"
rule, internal linkage is
>>>>>> a common convention for achieving this.
>>>>>>> 
>>>>>>> This is just Standardese for dealing with what
compiler
>>>>>>> implementers
>>>>>> typically handle as "internal linkage"
anyway; at the same time, the
>>>>>> use of 'static' for this purpose was
deprecated.  This is
>>>>>> specifically stated in C++98 section 7.3.1.1 and
unnamed namespaces
>>>>>> are still similarly defined in C++17 (Working Paper)
although the
>>>>>> specific reference to the deprecation of
'static' for this purpose is
>>>>>> now gone.
>>>>>>> 
>>>>>>> The closest the Standard gets to talking about
linkage is with
>>>>>>> Linkage
>>>>>> Specifications, and even here it tries to avoid to
avoid treading on
>>>>>> the definitions things like internal versus external
linkage.
>>>>>>> 
>>>>>>> So I am curious, what does this proposed attribute
on namespaces
>>>>>>> achieve
>>>>>> that cannot already be achieved with an anonymous or
unnamed
>>>>>> namespace?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>>    Martin O'Riordan - Movidius Ltd.
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: cfe-dev [mailto:cfe-dev-bounces at
lists.llvm.org] On Behalf Of
>>>>>> Evgenii Stepanov via cfe-dev
>>>>>>> Sent: 23 October 2015 22:41
>>>>>>> To: Steven Stewart-Gallus <sstewartgallus00 at
mylangara.bc.ca>
>>>>>>> Cc: Clang Dev <cfe-dev at lists.llvm.org>
>>>>>>> Subject: Re: [cfe-dev] [RFC]
__attribute__((internal_linkage))
>>>>>>> 
>>>>>>> Sounds right. The proposed attribute is a rough
equivalent of
>>>>>>> 
>>>>>>> static void foo::do_method(void)
>>>>>>> {
>>>>>>> // implementation here
>>>>>>> }
>>>>>>> 
>>>>>>> where "static" does not mean a static
class member, but makes the
>>>>>> declaration local to the translation unit. C-style
"static".
>>>>>>> 
>>>>>>> The patch in http://reviews.llvm.org/D13925
(waiting for review,
>>>>>>> btw!)
>>>>>> supports this attribute on classes and namespaces, with
this syntax:
>>>>>>> 
>>>>>>> namespace __attribute__((internal_linkage)) { }
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Oct 23, 2015 at 9:03 AM, Steven
Stewart-Gallus via cfe-dev
>>>>>>> <cfe-
>>>>>> dev at lists.llvm.org> wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> Can I ask for some clarification?
>>>>>>>> 
>>>>>>>> Apparently, C++ doesn't allow to static
class methods?
>>>>>>>> 
>>>>>>>> While in C one might write inside a header
file:
>>>>>>>> 
>>>>>>>> static inline void mylib_foo_do_method(struct
mylib_foo *foo) {
>>>>>>>>  // implementation here
>>>>>>>> }
>>>>>>>> 
>>>>>>>> In C++ the typical style would be to write
something like:
>>>>>>>> 
>>>>>>>> namespace mylib {
>>>>>>>> 
>>>>>>>> void foo::do_method(void)
>>>>>>>> {
>>>>>>>> // implementation here
>>>>>>>> }
>>>>>>>> }
>>>>>>>> 
>>>>>>>> Unfortunately, the C++ case then implies some
linkage behaviour
>>>>>>>> that some might not want.
>>>>>>>> 
>>>>>>>> Apparently, one can't do things like:
>>>>>>>> 
>>>>>>>> namespace mylib {
>>>>>>>> 
>>>>>>>> static void foo::do_method(void)
>>>>>>>> {
>>>>>>>> // implementation here
>>>>>>>> }
>>>>>>>> }
>>>>>>>> 
>>>>>>>> Or,
>>>>>>>> 
>>>>>>>> namespace {
>>>>>>>> namespace mylib {
>>>>>>>> 
>>>>>>>> static void foo::do_method(void)
>>>>>>>> {
>>>>>>>> // implementation here
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>> 
>>>>>>>> Also, if you wanted to an attribute to a whole
namespace you
>>>>>>>> should do something like the following I think:
>>>>>>>> 
>>>>>>>> namespace mylib {
>>>>>>>> [[clang::internal_linkage]];
>>>>>>>> 
>>>>>>>> static void foo::do_method(void)
>>>>>>>> {
>>>>>>>> // implementation here
>>>>>>>> }
>>>>>>>> }
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Steven Stewart-Gallus
>>>>>>>> _______________________________________________
>>>>>>>> cfe-dev mailing list
>>>>>>>> cfe-dev at lists.llvm.org
>>>>>>>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>> _______________________________________________
>>>>>>> cfe-dev mailing list
>>>>>>> cfe-dev at lists.llvm.org
>>>>>>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> LLVM Developers mailing list
>>>>>>> llvm-dev at lists.llvm.org
>>>>>>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev