| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/ruby/prism/commit/fef2c20777
|
|
They were being parsed as `p((p a, &block) => value)`.
When we get to this point, we must not just have parsed a command call, always consuming the `=>` is not correct.
Closes [Bug #21622]
https://github.com/ruby/prism/commit/796ab0edf4
|
|
https://github.com/ruby/prism/commit/e91f8dbb99
|
|
https://github.com/ruby/prism/commit/d5453f168e
|
|
Fix https://github.com/ruby/prism/pull/1468
Fix https://github.com/ruby/prism/pull/1575
To decide command-style method calls are allowed, this introduce a new
parameter `accepts_command_call` to `parse_expression` and some
functions.
Although one think this can be solved by operator precedence, it is
hard or impossible, because the precedence of command-style calls is skewed
(e.g. `! bar 1 ` is accepted, but `foo = ! bar 1` is rejected.)
One of the most complex examples is that:
(1) even though `foo = bar = baz 1` and `foo, bar = baz 1` is accepted,
(2) `foo, bar = baz = fuzz 1` is rejected.
To implement this behavior, this introduces a new binding power
`PM_BINDING_POWER_MULTI_ASSIGNMENT` and uses it for distinguish which single
assignments or multi assignments at their RHS.
https://github.com/ruby/prism/commit/d4dd49ca81
|
