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

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

[ibylich]

Issue #15789 has been reported by ibylich (Ilya Bylich).

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

* Author: ibylich (Ilya Bylich)
* Status: Open
* 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.



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

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

[merch-redmine]

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

File fix-numbered-parameter-in-optarg-default-value.patch added

Attached is a one-line patch that fixes this issue, hopefully without causing additional issues:

```ruby
m(a = ->{@1}); a end
m.call(1)
# => 1

m2 = ->(a = ->{@1}) {a}
m2.call.call(2)
# => 2

m3 = ->(a: ->{@1}) {a}
m3.call.call(3)
# => 3

def m(a = @1); a end
# SyntaxError ((irb):1: numbered parameter outside block

m2 = ->(a = @1) {a}
# SyntaxError ((irb):1: ordinary parameter is defined)
```


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

* Author: ibylich (Ilya Bylich)
* Status: Open
* 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)


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

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

[merch-redmine]

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

File fix-numbered-parameter-in-optarg-default-value-v2.patch added

jeremyevans0 (Jeremy Evans) wrote:
> Attached is a one-line patch that fixes this issue, hopefully without causing additional issues:

Here's a patch that includes tests for this fix.

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

* Author: ibylich (Ilya Bylich)
* Status: Open
* 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/

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

[nobu]

Issue #15789 has been updated by nobu (Nobuyoshi Nakada).


jeremyevans0 (Jeremy Evans) wrote:
> Attached is a one-line patch that fixes this issue, hopefully without causing additional issues:

Thank you, committed the patch.

> ```ruby
> m2 = ->(a = @1) {a}
> # SyntaxError ((irb):1: ordinary parameter is defined)
> ```

This should be the "outside block" error, I think.

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

* Author: ibylich (Ilya Bylich)
* Status: Open
* 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/

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

[merch-redmine]

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


nobu (Nobuyoshi Nakada) wrote:
> > ```ruby
> > m2 = ->(a = @1) {a}
> > # SyntaxError ((irb):1: ordinary parameter is defined)
> > ```
> 
> This should be the "outside block" error, I think.

I think the `ordinary parameter is defined` error makes sense if you consider the block starting at the `->` and not the `{`.  Especially when you consider the older lambda/proc syntax uses the same error:

```ruby
lambda { |a=@1| a }
# SyntaxError ((irb):1: ordinary parameter is defined)
```


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

* Author: ibylich (Ilya Bylich)
* Status: Open
* 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/

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

[nobu]

Issue #15789 has been updated by nobu (Nobuyoshi Nakada).


jeremyevans0 (Jeremy Evans) wrote:
> I think the `ordinary parameter is defined` error makes sense if you consider the block starting at the `->` and not the `{`.  Especially when you consider the older lambda/proc syntax uses the same error:
> 
> ```ruby
> lambda { |a=@1| a }
> # SyntaxError ((irb):1: ordinary parameter is defined)
> ```

I've thought inside braces and outside braces are different.

That is, in this code, the `@1` should mean the parameter of the outer `proc`.
```ruby
proc {->(a = @1) {a}}.call(42)
```

But now I changed the mind.
The scope inside parentheses should be separated from the outside.

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

* Author: ibylich (Ilya Bylich)
* Status: Open
* 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/

[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

[merch-redmine]

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/