On Apr 24, 2013, at 7:14 PM, Rafael Espíndola <[email protected]> wrote:
> On 24 April 2013 21:25, Weiming Zhao <[email protected]> wrote: >> Hi Rafael, >> >> >> >> Could you please check if the attached patch fixes the issue >> (http://llvm.org/bugs/show_bug.cgi?id=15841) correctly? >> > > I don't think this is the correct fix. getLanguageLinkageTemplate > should follow the structure of [dcl.link]. I think the real problem is > the context the friend function is getting. > > I went looking in the standard, and what I found was [namespace.memdef] p3: > > ------------------------------------------- > Every name first declared in a namespace is a member of that > namespace. If a friend declaration in a non-local class first declares > a class, function, class template or function template the friend is a > member of the innermost enclosing namespace. > ------------------------------------------ > > If I read that correctly, > > extern "C" { > class Foo { > friend void bar(); > }; > void bar() { > } > } > > is equivalent to > > void bar(); > extern "C" { > class Foo { > friend void bar(); > }; > void bar() { > } > } > > So I now think that clang is correct and the code should be rejected. > Richard, do you agree? Is this a defect? Linkage specifications don't actually have members under the standard. Instead, they just set the language linkage of any non-class-member name declared therein that has external linkage. That would seem to apply to a friend declaration. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
