-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix crash when an attribute node was used inside an unary op #8209
Conversation
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 was just writing a PR to fix this since I feel responsible for writing it! The real fix turns out to be
def _get_start_value(self, node: nodes.NodeNG) -> tuple[int | None, Confidence]:
inferred = utils.safe_infer(node)
start_val = inferred.value if inferred else None
return start_val, INFERENCE
when I initially wrote it I was just not as familiar with when to use inference so I was super conservative, but turns out this should handle all cases!
You'll also need to update the output .txt with my suggestion |
Isn't it better to not use inference all the time for performance ? |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #8209 +/- ##
=======================================
Coverage 95.45% 95.45%
=======================================
Files 177 177
Lines 18635 18635
=======================================
Hits 17788 17788
Misses 847 847
|
You'd know better than I :) but I guess here we're trading performance for preventing another one of these bugs in the future in case there is another type of |
I think at this point we pretty much covered all the crash cases, the issues are getting increasingly niche. But yeah it crashed a lot since initial implementation. π What do you think ?
I did not understand that part ? |
No need to update anything since we've discussed it. |
I have no idea if the performance are better with the current code compared to inference tbh. And what you proposed looks a lot better and also fail proof. |
π€ According to the primer, this change has no effect on the checked open source code. π€π This comment was generated for commit d933d3f |
@DanielNoord do you have an opinion on the subject ? |
This looks fine to me! I don't really unferstand the suggestion by @clavedeluna as |
β¦8225) Closes #8207 (cherry picked from commit 70f7e3a) Co-authored-by: Pierre Sassoulas <[email protected]>
Type of Changes
Description
Closes #8207