[ruby-core:22664] Re: [Bug #1240] parser bug in 1.8.7 and 1.9.1p0

On Mar 3, 2009, at 13:42 , Dave B wrote:

> As there's no context for this "bug", I've tried to provide some.

This isn't a "bug", it is a bug, as I think I've shown below.

> # Contrasting with ...
> p "#{}".z  { "GIGO\n".display }
> puts '---'
> p "#{}".z do "GIGO\n".display end
> # ... what was "do end" in the original report
> #  expected to bind to?


I find this view more clear:

> % echo 'p "#{}".z do "GIGO\n".display end' | parse_tree_show
> s(:iter,
>  s(:call,
>   nil,
>   :p,
>   s(:arglist, s(:call, s(:dstr, "", s(:evstr)), :z, s(:arglist)))),
>  nil,
>  s(:call, s(:str, "GIGO\n"), :display, s(:arglist)))

so the do/end (aka iter) is bound to the call to #p.

 From the original report, minus the empty interpolation:

> % echo 'x y { "".z do end }' | parse_tree_show
> s(:call,
>  nil,
>  :x,
>  s(:arglist,
>   s(:iter,
>    s(:call, nil, :y, s(:arglist)),
>    nil,
>    s(:iter, s(:call, s(:str, ""), :z, s(:arglist)), nil)))

the interpolation would replace the s(:str, "") with:

>  % echo '"#{}"' | parse_tree_show
> s(:dstr, "", s(:evstr))

So really there isn't any reason why this shouldn't be parseable. If  
this isn't solved by the weekend I'll take a whack at it with  
ruby_parser and translate/backport from there. I _hate_ these  
codepaths tho and I haven't gotten around to rewriting the string  
stack yet, so it isn't fun.