This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCHv2 2/4] gdb: Resolve 49 reduce/reduce conflicts in c-exp.y
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
Andrew> This commit splits the ptr_operator rule in c-exp.y in two, resolving
Andrew> 49 reduce/reduce conflicts in the process. There should be no
Andrew> user visible change after this commit.
Andrew> There are still 42 shift/reduce and 4 reduce/reduce conflicts
Andrew> remaining in c-exp.y (using GNU bison 3.0.4).
Andrew> gdb/ChangeLog:
Andrew> * c-exp.y (base_ptr_operator): New rule, with non-recursive
Andrew> content taken from...
Andrew> (ptr_operator): ...here, leaving just the recursion here.
Andrew> -ptr_operator:
Andrew> - ptr_operator '*'
Andrew> +base_ptr_operator
Andrew> + : '*'
Andrew> { insert_type (tp_pointer); }
Andrew> - const_or_volatile_or_space_identifier
Andrew> - | '*'
Andrew> - { insert_type (tp_pointer); }
Andrew> - const_or_volatile_or_space_identifier
Andrew> + const_or_volatile_or_space_identifier
Andrew> | '&'
Andrew> { insert_type (tp_reference); }
Andrew> - | '&' ptr_operator
Andrew> - { insert_type (tp_reference); }
Andrew> | ANDAND
Andrew> { insert_type (tp_rvalue_reference); }
Andrew> - | ANDAND ptr_operator
Andrew> - { insert_type (tp_rvalue_reference); }
I don't really understand the previous code here -- in particular why
the '*' case puts ptr_operator first, while the '&' and '&&' cases put
it second.
Does this patch change the order of calls to insert_type? I find it
hard to reason about what is going on here, so some assurance that it is
all ok would be good.
According to my --coverage build, the "'&' ptr_operator" and "ANDAND ptr_operator"
rules are not exercised by the test suite. So, if there is a change, it
wouldn't necessarily be noticed :(
Tom