-
Notifications
You must be signed in to change notification settings - Fork 28
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
Distinguish type error from name error in pyparser #733
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #733 +/- ##
==========================================
- Coverage 88.01% 88.00% -0.01%
==========================================
Files 86 86
Lines 20928 20965 +37
==========================================
+ Hits 18419 18450 +31
- Misses 2509 2515 +6 ☔ View full report in Codecov by Sentry. |
Not sure if I'm understanding codecov correctly, but it's mad that the new tests are not themselves tested? |
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.
Aren't you forgetting @proc
on function definitions in the test?
I was emulating the existing tests in test_uast.py which lack |
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.
Wait nvm I didn't see the rest of the test. LGTM. Can you double check that tests you added are actually run by pytest?
Yes, they are
Looking at the report, it is just flagging the test functions that are passed to the uast parser (since the funcs are defined only for their AST, they are not actually executed). |
Distinguish undefined variable error from type error in UAST parser
Previously, when parse_expr failed to resolve a name to a value, it always reported "undefined variable" errors regardless of whether the cause was due to failing to look up the name in the global/local scope, or due to correctly looking up the name but the value not being a valid type (e.g. the name resolving to a str value). I changed the parser to distinguish these 2 cases in the error message (see the new tests I added to see what I mean).