On Wed, 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? The governing rule is [dcl.link]p4: "[...] In a linkage-specification, the specified language linkage applies to [...] function names with external linkage [...] declared within the linkage-specification." "declared within" here is a lexical notion, and the friend function is declared within the linkage-specification. (Later in that paragraph, we have "A C language linkage is ignored in determining the language linkage of the names of class members and the function type of class member functions", but since a friend isn't a member, that doesn't apply.)
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
