Skip to content

+ ruby33.y: extract p_assoc and p_in rules#976

Merged
iliabylich merged 1 commit intowhitequark:masterfrom
iliabylich:extract-p_assoc-and-p_in
Dec 28, 2023
Merged

+ ruby33.y: extract p_assoc and p_in rules#976
iliabylich merged 1 commit intowhitequark:masterfrom
iliabylich:extract-p_assoc-and-p_in

Conversation

@iliabylich
Copy link
Collaborator

This commit tracks upstream commit ruby/ruby@3b05238.

Closes #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:

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.

@iliabylich iliabylich merged commit c03cdbb into whitequark:master Dec 28, 2023
@iliabylich iliabylich deleted the extract-p_assoc-and-p_in branch December 28, 2023 17:23
@iliabylich
Copy link
Collaborator Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ruby/ruby@3b05238

1 participant