Re: [C++ Patch] PR 19200 follow up

2014-06-11 Thread Jason Merrill
OK. Jason

[C++ Patch] PR 19200 follow up

2014-06-11 Thread Paolo Carlini
Hi, just reminded the hard way that, for friend *template* declarations, cp_parser_init_declarator (vs cp_parser_member_declaration) has to pass the actual friend_p information. I'm finishing testing the below. Thanks, Paolo. // /cp 2014-06-11 Paolo Carlini PR

Re: [C++ Patch] PR 19200

2014-06-11 Thread Jason Merrill
OK. Jason

Re: [C++ Patch] PR 19200

2014-06-10 Thread Paolo Carlini
Hi, On 06/10/2014 05:31 PM, Jason Merrill wrote: On 06/10/2014 11:19 AM, Paolo Carlini wrote: Back to you in a few hours, but I suspect we would have trouble with the famous struct S { friend S::S(); }; compiled with -fpermissive. I don't think so; that should be handled late

Re: [C++ Patch] PR 19200

2014-06-10 Thread Jason Merrill
On 06/10/2014 11:19 AM, Paolo Carlini wrote: Back to you in a few hours, but I suspect we would have trouble with the famous struct S { friend S::S(); }; compiled with -fpermissive. I don't think so; that should be handled later in grokdeclarator by if (declarator && d

Re: [C++ Patch] PR 19200

2014-06-10 Thread Paolo Carlini
Hi, > On 10/giu/2014, at 16:32, Jason Merrill wrote: > >> On 06/10/2014 05:58 AM, Paolo Carlini wrote: >>&& (friendp == 0 || dname == current_class_name)) > > Can't we just drop the dname condition here, rather than clear ctype later? > That seems to be specifically what we're fixing:

Re: [C++ Patch] PR 19200

2014-06-10 Thread Jason Merrill
On 06/10/2014 05:58 AM, Paolo Carlini wrote: && (friendp == 0 || dname == current_class_name)) Can't we just drop the dname condition here, rather than clear ctype later? That seems to be specifically what we're fixing: a friend is not a member function even if it has the same name a

Re: [C++ Patch] PR 19200

2014-06-10 Thread Paolo Carlini
Hi, On 06/10/2014 03:40 AM, Jason Merrill wrote: I think the parser approach is more correct. I suspected that, in fact it's the first approach I tried, but the additional parameter in many places made me a little nervous and persisted ;) On 06/09/2014 07:02 PM, Paolo Carlini wrote:

Re: [C++ Patch] PR 19200

2014-06-09 Thread Jason Merrill
I think the parser approach is more correct. On 06/09/2014 07:02 PM, Paolo Carlini wrote: !TYPE_WAS_ANONYMOUS (class_type) +&& !friend_p && constructor_name_p (unqualified_name,

[C++ Patch] PR 19200

2014-06-09 Thread Paolo Carlini
Hi, another old issue, which should be also relatively easy to fix. The problem is clear, for: struct S { struct T{}; friend void S(T); }; cp_parser_direct_declarator sees a name which matches that of a kosher constructor and sets sfk_constructor. Then things go quickly wrong because a