Skip to content

Conversation

@Earlopain
Copy link
Collaborator

As I understand it, the code operates line-by-line. When finding __END__, it has to decide if it is the end marker or just appears as part of of a multi-line literal (see tests).

Basically, if we found __END__ on a line by itself and there are syntax errors, it's impossible to be the end marker.

This is in preparation for #3911. That issue is caused by lex_modes not being properly reset after reaching EOF during heredoc body parsing. It is still in PM_LEX_EMBEXPR mode, which causes it to not reset the parser to the heredoc identifier end.

Tests are just formatted so it's better to see what they are doing.

As I understand it, the code operates line-by-line. When finding `__END__`, it has to decide if it is
the end marker or just appears as part of of a multi-line literal (see tests).

For a future PR I plan to make, `lex_modes` may be empty after parsing finished, even if it was syntax invalid.
Currently there will _always_ be errors when lex modes are not popped. So these extra checks are redundant.

Basically, if we found `__END__` on a line by itself and there are syntax errors, it's impossible to be the end marker.
@Earlopain Earlopain force-pushed the parse-stream-end-condition branch from be3da9d to 8b63780 Compare February 10, 2026 17:28
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.

1 participant