Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14283 > unrolled thread

Re: ./parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]

Started byChet Ramey <chet.ramey@case.edu>
First post2018-06-27 15:16 -0400
Last post2018-06-27 15:16 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: ./parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr] Chet Ramey <chet.ramey@case.edu> - 2018-06-27 15:16 -0400

#14283 — Re: ./parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]

FromChet Ramey <chet.ramey@case.edu>
Date2018-06-27 15:16 -0400
SubjectRe: ./parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
Message-ID<mailman.2642.1530127015.1292.bug-bash@gnu.org>
On 6/27/18 10:33 AM, Piotr Grzybowski wrote:
> 
> On 27 Jun 2018, at 14:57, Chet Ramey wrote:
> 
>> On 6/27/18 6:59 AM, Piotr Grzybowski wrote:
>>
>>> +function_newline_list: '(' ')' | function_newline_list '\n'
>>> +       ;
>>> +
>>
>> This would appear to allow constructs like
>>
>> foo()
>> () ()
>> {
>> 	function body
>> }
> 
> only by the look of things ;-) (thats what I meant in P.S.) actually those tokens are not allowed:
> 
> bash-5.0$ cat /tmp/m.sh
> foo()
> () ()
> {
>         function body
> }
> 
> bash-5.0$ . /tmp/m.sh
> bash: /tmp/m.sh: line 2: syntax error near unexpected token `)'
> bash: /tmp/m.sh: line 2: `() ()'
> 
>  I am sure function_newline_list can be rewritten in a better way though.

I don't really see the value. It doesn't solve any problems; it just lets
you feel better about the grammar. The shift-reduce behavior (shifting) is
what we want, anyway.

The problem is that the left paren is ambiguous given the syntax bash
supports (mostly for backwards compatibility).  If you've already read
`function name', and you read a left paren, you're stuck: you can shift
to `function name (' or reduce to `function name' and look to read a
subshell command. The only way to differentiate between the two requires
that you look ahead more than bison allows you.

That's why this gives a syntax error, and still does even after your
change:

function name ( echo subshell )

Technically we should support that, since we try to support the same
function body syntax for Posix and non-Posix function definitions, but the
grammar can't quite do it in its current form. The vast majority of the
time you're going to read a function definition `function name () compound-
command' anyway, and bison shifting gives you that.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web