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

Add VarNode class for lvar, ivar, cvar and gvar node types #204

Merged
merged 2 commits into from
Oct 29, 2024

Conversation

dvandersluis
Copy link
Member

Adds node classes for variables, to have symmetry with the assignment nodes. eg. a lvasgn and lvar for the same variable should have the same value for the #name method.

@@ -19,6 +19,7 @@ def namespace
def name
node_parts[1]
end
alias short_name name
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CasgnNode and Const should have a symmetrical interface so that they can be compared (eg. in Lint/SelfAssignment).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, but maybe the best would be to simply move all the implementation of Const to a module and include this here too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcandre if you can take another look, I have extracted the methods from ConstNode and included them in CasgnNode as well. I called the mixin ConstantNode but happy for a suggestion for a better name if you'd like.

This adds some new methods to CasgnNode to mirror ConstNode, so I've added tests for those as well.

@dvandersluis
Copy link
Member Author

@marcandre
Copy link
Contributor

marcandre commented Aug 13, 2021

Any ideas?

Sorry, that's my code 😅 .
It could be adapted so that it creates the right type of node, base on the existence of VarNode or not...?
Or change the test to compare [type, name] instead of the nodes directly.

@dvandersluis
Copy link
Member Author

dvandersluis commented Aug 17, 2021

Is there a way we can update s to return the right class instead of Node for all node types? That probably would be the "best" solution IMO.

It could be adapted so that it creates the right type of node, base on the existence of VarNode or not...?

Do you mean something like:

if defined?(RuboCop::AST::VarNode) ? RuboCop::AST::VarNode.new(...) : s(...)

Or change the test to compare [type, name] instead of the nodes directly.

I don't think we can do this because I think the issue is this fetch: https://github.com/rubocop/rubocop/blob/2fe4b1a6faca23adff13e1bbff6ecf5b66c6447b/lib/rubocop/cop/metrics/utils/repeated_attribute_discount.rb#L114

I've had a little trouble tracing what's happening in that class though so I may be offbase.

@bbatsov
Copy link
Contributor

bbatsov commented Oct 25, 2024

@dvandersluis Let me know if you're interested in reviving this PR, so we can drive it to the finish line.

@dvandersluis
Copy link
Member Author

Sure, I'll take another look.

@dvandersluis dvandersluis force-pushed the var-nodes branch 3 times, most recently from 09db497 to beb2e66 Compare October 28, 2024 21:53
@dvandersluis
Copy link
Member Author

So it looks like in the interim since this was last touched, the s() method was updated to return a specific node type instead of the generic Node, which fixes the issues I described above.

@marcandre @bbatsov if you're able please take a look 🙌

Copy link
Contributor

@marcandre marcandre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thank you 💪

@marcandre marcandre merged commit 0b334f8 into rubocop:master Oct 29, 2024
19 checks passed
@marcandre
Copy link
Contributor

marcandre commented Oct 29, 2024

Let me know if you need a release quickly for this, otherwise this will be released whenever the other upcoming issues & PR are resolved / soonish

@dvandersluis
Copy link
Member Author

dvandersluis commented Oct 29, 2024

No rush on my end! Thanks @marcandre!

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.

3 participants