Racc doesn't have access to a result of a p_assoc rule in the last mid-rule of the diff (probably because of a lookahead?) and so it can't read $ctxt.in_kwarg. If that's true for Lrama then it's a very nasty bug that I don't see exactly how to reproduce :(. It could be something like this:
def foo a: case 1; in 1; then 1; end, b:
p 42
end
that gets rejected (this particular snippet is accepted by MRI which is correct). It could even be a UB if generated code reads uninitialised memory and transmutes it to ctxt (then it becomes a heisenbug) but I hope Ruby CI runs ASAN for all of its tests.
cc @nobu, I hope it's a false alarm and Lrama does everything right but could you PTAL? Do all mid-rules have access to results of previous mid-rules in the scope of the same derivation?
This commit tracks upstream commit ruby/ruby@3b05238.
Closes https://github.com/whitequark/parser/issues/951.
Racc doesn't have access to a result of a
p_assoc
rule in the last mid-rule of the diff (probably because of a lookahead?) and so it can't read$ctxt.in_kwarg
. If that's true for Lrama then it's a very nasty bug that I don't see exactly how to reproduce :(. It could be something like this:that gets rejected (this particular snippet is accepted by MRI which is correct). It could even be a UB if generated code reads uninitialised memory and transmutes it to
ctxt
(then it becomes a heisenbug) but I hope Ruby CI runs ASAN for all of its tests.