Re: [PATCHv2 0/4] gdb: Allow struct fields named double

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Andrew Burgess <andrew.burgess@embecosm.com> [2018-12-18 22:40:09 +0000]:

> Simon, Tom,
> 
> Thanks for the feedback.
> 
> * Tom Tromey <tom@tromey.com> [2018-12-16 09:42:15 -0700]:
> 
> > >>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> > 
> > Simon> This looks reasonable to me, from the user point of view there is not reason
> > Simon> why x.double would be different from x.float.  With the same logic, we should
> > Simon> also allow x.int, x.short, etc.  But I'm fine with doing it on an as-needed basis.
> > 
> > See also https://sourceware.org/bugzilla/show_bug.cgi?id=13368
> 
> The new patch series includes a patch that extends some of the
> comments in order to hopefully address this bug.
> 
> > 
> > Simon> This LGTM, with one thing below you might want to change.  I'm far from an expert
> > Simon> in parsers though, so please give others ~1 week to comment, and push then if you
> > Simon> don't receive additional feedback.
> > 
> > I think the main possible issue is if this introduces a new parser conflict.
> > Taking a glance at the uses of "name" in the grammar, though, it seems
> > safe enough.
> 
> I took a better look at how the YACC step of the compile works, and it
> turns out that parser conflicts are not fatal to the build, and my
> change had introduced a new conflict.
> 
> The new patch series addresses this by focusing my change specifically
> on structure field names, so I want to be able to parse:
> 'object.double', but I don't expect to be able to parse an object
> named 'double'.  I also extended my patch to cover other types like
> 'int', 'short', etc.
> 
> As penance I've included a patch that tweaks how pointers are parsed
> that resolves 49 reduce/reduce conflicts.
> 
> After this series there's still 42 shift/reduce conflicts, and 4
> reduce/reduce conflicts in the C parser, but patch #4, the one I
> really care about, doesn't introduce any new conflicts.
> 
> Tested on X86-64 GNU/Linux.
> 

Tom,

Thanks for the feedback on the revised patch series.  I have gone
ahead and pushed 1, 3, and 4, dropping patch 2.

For patch #4 I confirmed there are no duplicate test names.

In patch #2, you are correct and that the type stack is parsed in a
slightly different order with the patch than before.  I don't know if
this is significant, but I certainly don't know that it's not.

I'm convinced that patch #2 could be made to work, but I don't have
time right now, so I'll add it to my ever-growing todo list.

Thanks,
Andrew