[ruby-core:92603] [Ruby trunk Bug#15789] Parse error when numbered parameter is used in a lambda that is a default value of other optarg

Issue #15789 has been updated by jeremyevans0 (Jeremy Evans).

Status changed from Open to Closed

nobu committed my fix for this at commit:bb4ac7a6506971dc34b5656f1a69aadc7299fcab

----------------------------------------
Bug #15789: Parse error when numbered parameter is used in a lambda that is a default value of other optarg
https://bugs.ruby-lang.org/issues/15789#change-77962

* Author: ibylich (Ilya Bylich)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.7.0dev (2019-04-24 trunk cf930985da) [x86_64-darwin18]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
Sorry if the name of the ticket is not desccriptive

While working on backporting these commits into a parser gem:
https://github.com/ruby/ruby/commit/6ca9e7cc0785c33f6d382176dbd79d6c91db72fe
https://github.com/ruby/ruby/commit/ae07b66aaa092c59ac9d544c9b582712290dc357

... I've found a weird case that throws a SyntaxError:

``` ruby
> def m(a = ->{@1}); end
SyntaxError ((irb):10: ordinary parameter is defined)
def m(a = ->{@1}); end
             ^~
```

And same errors gets thrown when I pass a lambda with numparams to lambda optarg:
``` ruby
> ->(optarg = ->{@1}) {}
SyntaxError ((irb):1: ordinary parameter is defined)
->(optarg = ->{@1}) {}
               ^~
```

I guess the reason for that is that p->max_numparam should be organized as a stack, not a plain shared value.

---Files--------------------------------
fix-numbered-parameter-in-optarg-default-value.patch (546 Bytes)
fix-numbered-parameter-in-optarg-default-value-v2.patch (1.42 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>