Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assume an eval context for Prism::Translation::Parser #2741

Merged
merged 1 commit into from
May 3, 2024

Conversation

Earlopain
Copy link
Contributor

This is similar to davidwessman/syntax_tree-erb#81 but for RuboCop. The parser gem doesn't support these types of checks, see https://github.com/whitequark/parser?tab=readme-ov-file#syntax-check-of-block-exits

While this is technically a bug in the parser gem, it does increase compatibility and allows prism to be used when linting erb or haml through a RuboCop extension.

This is similar to davidwessman/syntax_tree-erb#81 but for RuboCop
The parser gem doesn't support these types of checks,
see https://github.com/whitequark/parser?tab=readme-ov-file#syntax-check-of-block-exits

While this is technically a bug in the parser gem, it does increase compatibility
and allows prism to be used when linting erb or haml with a RuboCop extension.
rafaelfranca added a commit to Shopify/packwerk that referenced this pull request May 2, 2024
Top level yields are invalid Ruby on files, but are valid on `eval`.

They exist on ERB files, and since those files are evaluated no written
to disk they are fine.

We can tell Prism to parse the code using the eval context by passing
`scopes: [[]]` to `parse`, but since are are using the
`Prism::Translation::Parser` class we have no way to do that.

A [PR][1] was proposed to Prism to always consider the code as being
evaluated in the `Parser` translation.

For now, we can safely ignore that class of error by overriding the
`valid_error?` method on our own parser.

Fixes #400.

[1]: ruby/prism#2741
rafaelfranca added a commit to Shopify/packwerk that referenced this pull request May 2, 2024
Top level yields are invalid Ruby on files, but are valid on `eval`.

They exist on ERB files, and since those files are evaluated no written
to disk they are fine.

We can tell Prism to parse the code using the eval context by passing
`scopes: [[]]` to `parse`, but since are are using the
`Prism::Translation::Parser` class we have no way to do that.

A [PR][1] was proposed to Prism to always consider the code as being
evaluated in the `Parser` translation.

For now, we can safely ignore that class of error by overriding the
`valid_error?` method on our own parser.

Fixes #400.

[1]: ruby/prism#2741
@kddnewton kddnewton merged commit 3452258 into ruby:main May 3, 2024
55 checks passed
@Earlopain Earlopain deleted the parser-translator-scope branch May 3, 2024 15:22
Earlopain added a commit to Earlopain/rubocop that referenced this pull request Jun 10, 2024
Most of these got disabled in rubocop#12822

It is however rather important that these cases parse sinc
some extensions rely on parsing code line by line.
This is the case when extracting code from a templating language like erb or haml

Prism was changed to allow these cases in ruby/prism#2741

`packwerk`ran into issue: Shopify/packwerk#400
I myself observed the same in `rubocop-erb`
Earlopain added a commit to Earlopain/rubocop that referenced this pull request Jun 10, 2024
Most of these got disabled in rubocop#12822

It is however rather important that these cases parse sinc
some extensions rely on parsing code line by line.
This is the case when extracting code from a templating language like erb or haml

Prism was changed to allow these cases in ruby/prism#2741

`packwerk`ran into issue: Shopify/packwerk#400
I myself observed the same in `rubocop-erb`
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.

2 participants