ruby.git/test/prism/fixtures/command_method_call.txt, branch v4.0.4

[ruby/prism] Revert "Reject `p(p a, &block => value)` and similar"

2025-11-23T21:36:19+00:00

https://github.com/ruby/prism/commit/fef2c20777

[ruby/prism] Reject `p(p a, &block => value)` and similar

2025-11-23T18:15:15+00:00

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

[ruby/prism] Add test cases

2023-12-05T15:16:42+00:00

https://github.com/ruby/prism/commit/e91f8dbb99

[ruby/prism] Fix some corner cases

2023-12-05T15:16:41+00:00

https://github.com/ruby/prism/commit/d5453f168e

[ruby/prism] Fix to parse command-style method calls more correctly

2023-12-05T15:16:40+00:00

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