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
[Fixes #44] Use parser's new emit_forward_arg by default #52
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,6 +14,8 @@ module AST | |
# parser = Parser::Ruby25.new(builder) | ||
# root_node = parser.parse(buffer) | ||
class Builder < Parser::Builders::Default | ||
self.emit_forward_arg = true | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shouldn't we leave it to RuboCop to set this, for the sake of consistency in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Contrary to the other There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough. |
||
|
||
NODE_MAP = { | ||
and: AndNode, | ||
alias: AliasNode, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a more salient point here is that most tools using
parser
use the legacy format, that's why it's a safer default.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite possible (by choice or because they aren't aware of it). I know some are using the "modern" AST (
unparser
,ruby-next
), but my tool (DeepCover
) doesn't, by ignorance first and by choice now 😆I'm not sure what you mean by "safer".
My objective is to be useful. Have you actually looked closely at the
emit_...
flags?In my opinion, while they reflect an actual difference in the language, all of them are insignificant over-complexifications for the vast majority of tools and Rubyists.
For example:
-> {}
andlambda {}
are indeed different in theory because one could, for example, redefine the methodlambda
while the first form woudn't be affected. I'd venture to say that the vast majority ofparser
uses don't care one bit about that difference. ForRuboCop
there might be a single cop caring about it (fixing the preference of one form over the other); all other cops probably prefer the simplicity of having to deal with the same AST for both constructs.Some are even more obscure. I personally much prefer an AST of
(send _ :[]= ...)
; it's how I think aboutfoo[42]= :bar
. I've yet to seefoo.[]=(42, :bar)
in the wild and it's quite sad that it forcedparser
to introduce a different AST for this.emit_forward
is different. It was actually a bad decision and the AST emitted without it is of a strange structure (forward-args
not inside anargs
, ...) and is not forward compatible with 2.8. My opinion is that it should be turned on by default by all tools that are aware of it.Are there
emit_...
that you feel are actually useful when turned on?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant it's less likely to surprise someone with the modern parser output. Maybe that's not a big problem in practice.
Yeah, I have. Generally most of the changes didn't add much value for us, that's why I never felt compelled to update the code. The biggest practical issue is obviously the big number of extensions that would suffer if we update the format, so for such changes we should always have a good reason. I'm fine with updating
forward-args
, as it has a relatively small impact, but I want to make sure people understand our rationale.