Re: [C++ Patch] PR 58650

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi again,

On 12/16/2014 11:17 AM, Paolo Carlini wrote:
> Hi,
>
> On 12/15/2014 11:25 PM, Jason Merrill wrote:
> > Why does error recovery fail?  I would expect to be able to just drop 
> > the 'friend' and treat it as a normal non-static data member.
> I agree, that was my first thought too. Unfortunately we do 
> non-trivial preparatory work *before* calling grokdeclarator based on 
> ds_friend which aren't reverted by locally resetting friendp in 
> grokdeclarator, and, eg, build_this_parm gets a null type even if 
> declspecs->locations[ds_friend] itself is reset right at the beginning 
> of grokdeclarator. I'll try the further investigate the above...
In better detail: grokdeclarator is called, via grokfield, by 
cp_parser_member_declaration. The latter stores the friendship 
information in a friend_p local flag, which remains true when 
grokdeclarator returns. Then at the end of the function:

      if (decl)
        {
          /* Add DECL to the list of members.  */
          if (!friend_p)
        finish_member_declaration (decl);

makes all the difference for the crash. Now, I could try resetting in 
grokdeclarator the primary ds_friend information as stored in the 
decl_specifiers and read it back, thus update friend_p in 
cp_parser_member_declaration. It would probably work, but frankly this 
fiddling only for error recovery makes me a little nervous. What do you 
think?

Thanks,
Paolo.