Make type inference failures more consistent #7079
Conversation
| @@ -996,7 +996,7 @@ IntNode[int](1, 1) | |||
| IntNode[int](1, 'a') # E: Argument 2 to "Node" has incompatible type "str"; expected "int" | |||
|
|
|||
| SameNode = Node[T, T] | |||
| ff = SameNode[T](1, 1) # E: Need type annotation for 'ff' | |||
| ff = SameNode[T](1, 1) | |||
There was a problem hiding this comment.
I think that this should generate an error, since T is not in scope here. If this seems unrelated, you can create an issue about this (and add a TODO comment here).
| @@ -2716,3 +2716,34 @@ class N(NamedTuple): | |||
| ) | |||
| b | |||
| [builtins fixtures/tuple.pyi] | |||
|
|
|||
| [case testNewAnalyzerLessErrorsNeedAnnotation] | |||
There was a problem hiding this comment.
What about adding a test case for x = [] # type: ignore followed by reveal_type(x)?
|
|
||
| class SetNothingToAny(TypeTranslator): | ||
| """Replace all ambiguous <nothing> types with Any (to avoid spurious extra errors).""" | ||
| def visit_uninhabited_type(self, t: UninhabitedType) -> Type: |
There was a problem hiding this comment.
Style nit: add empty line after class docstring.
| def is_valid_inferred_type_component(typ: Type) -> bool: | ||
| """Is this part of a type a valid inferred type? | ||
| class NothingSeeker(TypeQuery[bool]): | ||
| """Find any <nothing> types resulting from failed (ambiguous) type inference.""" |
There was a problem hiding this comment.
Style nit: add empty line after class docstring.
| @@ -205,8 +205,7 @@ def h() -> None: | |||
| [out] | |||
| == | |||
| a.py:3: error: Invalid type "b.C" | |||
| b.py:6: error: Need type annotation for 'c' | |||
| b.py:7: error: Cannot determine type of 'c' | |||
| b.py:7: error: C? has no attribute "g" | |||
There was a problem hiding this comment.
Hmm do we now propagate unbound types in type inference? Not sure if that's a good or bad thing.
There was a problem hiding this comment.
Not sure if that's a good or bad thing.
This is rather bad, but I believe the right solution is #4987.
See the discussion in PR #6450 and the change in |
Fixes #6998
This PR makes several related changes:
Cannot determine typeerror for cases where node deferral failed etc (for example with runtime recursive definitions); don't show it after failed (ambiguous) type inference.List[Any]for an empty list).Need type annotation for variableerror, not just for instances and tuples (that was ad-hoc IMO)This may actually give some new errors as compared to status quo, but as one can see from the diff, the result is negative in number of (redundant) errors.
There are couple changes in tests that look unrelated, these are because
is_same_type(..., UnboundType())returnsTruefor everything, includingUninhabitedType. I would say we should actually avoid leaking unbound types from semantic analysis and replace the, withAny, but this is a separate issue.