Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 name resolution to threading codemod #71
add name resolution to threading codemod #71
Changes from all commits
2e584f4
084851a
08138e6
9cc3f8a
a27a063
969d6bb
800fb77
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
As it currently is, It's grabbing the names based on the global scope. This means no matter where the
Lock()
call is detectedcurrent_names
will always return the same names.You should calculate the
current_names
at__init__
and update it accordingly when you add a new name.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.
this is correct and I believe exactly what we want. When we hit this threading codemod at
leave_With
, we are hitting a module's with clause. With the current approach, we grab the entire module where the with clause is located and find all the variable / import names. This means we will attempt to never pick a variable name for the lock at any scope, even if we could picklock
bc it's used in some other function. This is the safest thing.Calculating current_names at init will result in the exact same thing but the downside is that we have to update the codemod architecture. With this approach, all I had to do is to update
leave_With
and callfind_used_names_in_module
. This architecture is more generalizable than adding an init call.If you think I'm mistaken here give me a unit test that would fail the current approach so I can iterate.
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.
This is more of a question but I'm unclear what "global" scope means in this context. Is it the module-level scope? Or is it some kind of scope containing all variables declared anywhere in the module? I would be rather surprised to find out that it's the latter. But here's a potential test case:
I'm definitely curious about this, especially since I think all of the existing test cases are implemented in terms of module-level scope.
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.
It is exactly this. I said it somewhere along the lines but it will in fact find all variable / import names. This is good bc it's extra safe, but of course there are scopes in which we could reuse but we don't.
I"ve added the test case that you've pointed out and it passes as expected - we add a new
lock_1
variable right underlock = "whatever"
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.
It's module-level scope. I believe the current implementation will be able to detect the conflict in your particular example.
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 we need another test here:
This case probably isn't such a concern because variable reuse is probably acceptable. But we also need another test case:
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.
@andrecsilva wondering if these are the cases you're referring to by suggesting to implement get current names at init? because right now the codemod will change
to
which is not great since it itself is adding a name clash. This is happening because both calls to
leave_With
happen one after the other, with the second one not "learning about" the new addition of the firstlock = ...
. I don't believe this would be solved by movingcurrent_names = self.find_used_names_in_module()
to codemod init because that too will happen only once.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.
Yes, this was what I was afraid it would happen.
To reiterate, my suggestion is moving the calculation of
current_names
toWithThreadingLock
's__init__
and updatecurrent_names
with the newly added name withinleave_With
.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.
ahh I see what you mean now.
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.
notice this test. libcst processes the internal with statement first, so our naming will be like this. Not a huuuge deal