I've been seeing this for a while now:
```
../../../../ext/prism/../../src/memchr.c: In function ‘pm_memchr’:
../../../../ext/prism/../../src/memchr.c:35:16: warning: return discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
35 | return memchr(memory, character, number);
| ^~~~~~
```
https://github.com/ruby/prism/commit/a3b1f10dbc
(cherry picked from commit ce398d7545)
Change rescue modifier binding power from PM_BINDING_POWER_COMPOSITION
to PM_BINDING_POWER_MATCH + 1, so that `x = a rescue b in c` is parsed
as `(x = (a rescue b)) in c` and `def f = a rescue b in c` is parsed
as `(def f = (a rescue b)) in c`.
https://github.com/ruby/prism/commit/7e797f59ae
in is a unique keyword because it can be the start of a clause or
an infix keyword. We need to be explicitly sure that even though in
_could_ close an expression context (the body of another in clause)
that we are not also parsing an inline in. The exception is the
case of a command call, which can never be the LHS of an expression,
and so we must immediately exit.
[Bug #21925]
[Bug #21674]
https://github.com/ruby/prism/commit/20374ced51
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
When you have a regular expression that has a named capture that
has an escape sequence in the named capture, and that escape
sequence is a unicode escape sequence with an invalid surrogate
pair, the error was attached to the owned string as opposed to a
location on the shared source.
https://github.com/ruby/prism/commit/793a7a6a0a
When you have a heredoc interpolated into another heredoc where
the inner heredoc is terminated by a newline, you need to avoid
adding the newline character a second time.
https://github.com/ruby/prism/commit/8eeb5f358b
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
See https://bugs.ruby-lang.org/issues/21756. Ripper fails to parse this,
but prism actually also doesn't handle it correctly.
When heredocs are used, even in lowercase percent arays there can be
multiple `STRING_CONTENT` tokens. We need to concat them.
Luckily we don't need to handle as many cases as in uppercase arrays where interpolation is allowed.
https://github.com/ruby/prism/commit/211677000e
Hide the initialization of the base node inside the node
initializer lists by a macro. As such, consistently enforce flags
are set properly.
https://github.com/ruby/prism/commit/c7b3d66d84
When you have a %-literal that is delimited by newlines, and you
are also interpolating a heredoc into that literal, then both
concepts will attempt to add the same newline to the newline list.
https://github.com/ruby/prism/commit/c831abb888
The unicode version has been updated upstream, which means new
codepoints mapped to alpha/alnum/isupper flags. We need to update
our tables to match.
I'm purposefully not adding a version check here, since that is
such a large amount of code. It's possible that we could include
different tables depending on a macro (like UNICODE_VERSION) or
something to that effect, but it's such a minimal impact on the
running of the actual parser that I don't think it's necessary.
https://github.com/ruby/prism/commit/78925fe5b6
When we are about to destroy a node because of a syntax error, we
need to check if it is potentially containing an implicit
parameter in its subtree.
https://github.com/ruby/prism/commit/1531433e02
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
Takashi Kokubun