-
Notifications
You must be signed in to change notification settings - Fork 198
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
AST for rightward-assignment #738
Comments
Right, but what about linters? IIRC rubocop is based on a source rewriter, not on unparser, and so potentially it can easily reformat What's gonna happen if you have code like a
.b
.c
.d => e and you run a
.b
.c
e=.d I'm not super opinionated, we can easily change it. The main reason why I like adding new nodes is that some users don't read updates or don't update their code that depends on |
Right, for sure new syntax will probably require some kind of update to A quick search for |
+1
Do we want to be not only backward-compatible but forward-compatible as well 🙂? On the other hand, tools that care about the original source format would have to switch from AST-defined difference to some internal knowledge (and deal with
Since the feature is pretty simple, adding support for it would also be simple for any library. For example, that's what we need to make RuboCop VariableForce understand it: |
I feel we've had this whole discussion before, I'm not sure we want to have it again 😅 One of the conclusion was that the principle that a any new language feature implies a new AST type was not necessarily the right way to go. The other conclusion was that "how" something is written is in the location (think For the one-line For the right assign, there is not even a location that can newly be potentially The AST produced feels even more wrong than in the > ruby-parse --28 -e '@foo = 1'
(ivasgn :@foo
(int 1))
> ruby-parse --28 -e '1 => @foo'
(rasgn
(int 1)
(ivasgn :@foo)) What argument / principle leads to the conclusion that one-line definition => keep same AST type & structure and right assign => use different AST type and structure? For me, it's the same thing, and the same answer applies. |
One argument I have is having a natural order of nodes in AST (i.e., similar to the source code):
|
Ok, I agree, let's remove > ./miniruby --dump=parsetree -e 'a = 1'
###########################################################
## Do NOT use this node dump for any purpose other than ##
## debug and research. Compatibility is not guaranteed. ##
###########################################################
# @ NODE_SCOPE (line: 1, location: (1,0)-(1,5))
# +- nd_tbl: :a
# +- nd_args:
# | (null node)
# +- nd_body:
# @ NODE_LASGN (line: 1, location: (1,0)-(1,5))*
# +- nd_vid: :a
# +- nd_value:
# @ NODE_LIT (line: 1, location: (1,4)-(1,5))
# +- nd_lit: 1
> ./miniruby --dump=parsetree -e '1 => a'
###########################################################
## Do NOT use this node dump for any purpose other than ##
## debug and research. Compatibility is not guaranteed. ##
###########################################################
# @ NODE_SCOPE (line: 1, location: (1,0)-(1,6))
# +- nd_tbl: :a
# +- nd_args:
# | (null node)
# +- nd_body:
# @ NODE_LASGN (line: 1, location: (1,0)-(1,6))*
# +- nd_vid: :a
# +- nd_value:
# @ NODE_LIT (line: 1, location: (1,0)-(1,1))
# +- nd_lit: 1 |
Great. I'll make a PR |
Fixed in #739 |
Thanks! |
@mbj Well, maybe, it was leaking syntax, but now Unparser fails to correctly handle it: |
@palkan interesting, right assignment is > 2.7, correct? I've lost track. Unparser currently only aims at 2.7, but I'm making a list for > 2.7 already. |
@mbj Yep. I posted it here as an example demonstrating that the existing tools still should care about this syntax, even though the AST is the same as for the left assignment. |
Yeah, it likely requires some sensing, just like in case of It could be that some AST structures "only" can be produced from a righthand assignment, which than needs unparser to also emit it for round tripping. |
That's the case here. |
Yeah, I think unparser, once I get to 3.x support can easily detect these from the AST structure. |
I must apologize to be late to the party (again 😅), but I have to ask... is the AST for rightward assignment the best we can output? #682
I feel the same arguments as for the endless method definition's AST in #676 stand... Rightward assignment is pure syntax sugar and there is never any difference in execution between
foo => var
andvar = foo
(that I know of) so ideally the AST would reflect that.If we output a standard
lvasgn
(and it is a local var assignment), then many tools that only care about which variables are assigned to what will not even need to be updated, since in this case the locations are even exactly the same (except that thename
location is after theoperator
location instead of before). For example, I suspectunparser
would work out of the box withlvasgn
and produce 100% correct code. I didn't check, but I believeDeepCover
would too.cc/ @palkan
The text was updated successfully, but these errors were encountered: