They currently complain that the parent method is not forwarding.
But the actual problem is that these types of arguments simply don't
accept `...`
Fixes [Bug #21927]
https://github.com/ruby/prism/commit/0aa2363331
The lexer did not jump to the `heredoc_end`, causing the heredoc end delimiter
to be parsed twice.
Normally the heredocs get flushed when a newline is encountered. But because
the newline is part of the string delimiter, that codepath is not taken.
Fixes [Bug #21758]
https://github.com/ruby/prism/commit/7440eb4b11
When a pattern match is using a string as a hash pattern key and is
using it incorrectly, we were previously assuming it was a symbol.
In the case of an error, that's not the case. So we need to add a
missing node in this case.
https://github.com/ruby/prism/commit/f0b06d6269
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
When there are nested capture variables inside of a pattern match
that has an alternation pattern, it is a syntax error. Currently it
only adds a syntax error when it is at the top level of the pattern.
This one has been on my mind for a while now.
Currently, there are only tests against the latest syntax version.
This changes the snapshot structure as follows:
* Snapshots at their current location are tested against all syntax versions
* Snapshots inside a version folder like "3.3" are tested against all versions starting from that version
* Snapshots inside a version folder like "3.3-4.2" are tested against all versions in the given range.
This makes sure that as new syntax is added, older versions still work as expected.
I also added a few tests for now valid syntax that should be invalid in older versions (and the other way around as well)
These tests run really fast. So even though it does 3x the work for these, I am still able to run the whole test suite in just 11 seconds.
https://github.com/ruby/prism/commit/5191b1aa68
This adds a new error for the following reason:
* `def foo arg = nil` is interpreted as a normal method call with optional `arg` without matching `end`
* `def foo *arg = nil; end` is interpreted as a endless method call that has body `nil` with extraneous `end`
`def foo *arg = nil` is somewhere inbetween and I don't know how to otherwise indicate the error.
Now the second case above also shows the newly added error message.
Fixes [Bug #21623]
https://github.com/ruby/prism/commit/e1910d4492
Previously, endless method definitions in assignment contexts like
`x = def f = p 1` would fail to parse because command calls (method
calls without parentheses) were only accepted when the surrounding
binding power was less than `PM_BINDING_POWER_COMPOSITION`.
This fix specifically checks for assignment context and allows command
calls in those cases while maintaining the existing behavior for other
contexts. This ensures that:
- `x = def f = p 1` parses correctly (previously failed)
- `private def f = puts "Hello"` still produces the expected error
https://github.com/ruby/prism/commit/722af59ba3
When arithmetic expressions like `-1**2` are used in pattern matching contexts,
Ruby crashes with "Unexpected node type in pattern matching expression: PM_CALL_NODE".
This happens because the Prism parser creates `PM_CALL_NODE` for arithmetic operations,
but Ruby's pattern matching compiler doesn't handle call nodes.
This fix adds validation to reject `PM_CALL_NODE` in pattern contexts with a proper
syntax error.
https://github.com/ruby/prism/commit/365049a767
Prism was already disallowing arguments after block args, but in
parse.y, any comma after a block arg is a syntax error. This moves the
error handling into `PM_TOKEN_UAMPERSAND` where we can check if the
current type is `PM_TOKEN_COMMA`then raise an error. I've also updated
the tests to include the examplesfrom ruby/prism#3112.
Fixes: ruby/prism#3112https://github.com/ruby/prism/commit/754cf8eddc
If we hit an EOF token, and the character before the EOF is a newline,
we should make EOF token start at the previous newline. That way any
errors reported will occur on that line.
For example "foo(\n" should report an error on line 1 even though the
EOF technically occurs on line 2.
[Bug #20918]
https://bugs.ruby-lang.org/issues/20918https://github.com/ruby/prism/commit/60bc43de8e