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.
