Re: [PATCHv2 2/4] gdb: Resolve 49 reduce/reduce conflicts in c-exp.y

[Tom Tromey <tom@tromey.com>]

>>>>> "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