This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 58650
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Jason Merrill <jason at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 16 Dec 2014 11:40:09 +0100
- Subject: Re: [C++ Patch] PR 58650
- Authentication-results: sourceware.org; auth=none
- References: <548F5C8E dot 6000008 at oracle dot com> <548F5FEB dot 7020300 at redhat dot com> <549006BE dot 1040801 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.