-
Notifications
You must be signed in to change notification settings - Fork 262
Edit error marker comments on some tests #2048
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
Conversation
@@ -23,8 +23,13 @@ class Color(Enum): | |||
# > constructor. Instead, the call performs a value-based lookup of an | |||
# > enum member. | |||
|
|||
assert_type(Color["RED"], Color) # 'Literal[Color.RED]' is also acceptable |
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.
felt odd to assert_type here and say that another type is also acceptable. I tried to put both versions down, so that type checkers have discretion on which one to implement w/o the test failing.
I assume that if a checker emits an error on both lines the test will fail - could the maintainers please confirm this assumption?
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.
That's right; this is documented in the "Test case syntax" section in conformance/README.
@@ -65,7 +65,7 @@ def method3() -> None: # E[method3] | |||
pass | |||
|
|||
@overload # E[method4] | |||
def method4(self, x: int) -> int: | |||
def method4(self, x: int) -> int: # E[method4] |
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.
Pyrefly emits diagnostics on the line of the def
, not the line with the @overload
This is similar to what I did in #1980
See inline comments for why