Skip to content
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

Avoid redundant extra errors after "Need type annotation for variable" #6998

Closed
ilevkivskyi opened this issue Jun 15, 2019 · 0 comments · Fixed by #7079
Closed

Avoid redundant extra errors after "Need type annotation for variable" #6998

ilevkivskyi opened this issue Jun 15, 2019 · 0 comments · Fixed by #7079
Assignees
Labels

Comments

@ilevkivskyi
Copy link
Member

Consider this (oversimplified) example:

from typing import TypeVar, Optional

T = TypeVar('T')

def f(x: Optional[T] = None) -> T: ...

x = f()  # Need type annotation for 'x'
y = x  # Cannot determine type of 'x'

def g() -> None:
    x = f()  # Need type annotation for 'x'
    y = x  # Cannot determine type of 'x'

The subsequent errors look redundant (and maybe even annoying). This is more important with the new semantic analyzer because the old one doesn't show the error if the problematic variable was defined at the function scope.

Potentially, we can replace <nothing> with Any after we show the error. Also the code that detects failed inference can be improved. For example, is_valid_inferred_type() should be replaced with a proper type visitor.

@JukkaL JukkaL self-assigned this Jun 17, 2019
@ilevkivskyi ilevkivskyi self-assigned this Jun 26, 2019
ilevkivskyi added a commit that referenced this issue Jun 27, 2019
Fixes #6998

This PR makes several related changes:
* Reserve `Cannot determine type` error for cases where node deferral failed etc (for example with runtime recursive definitions); don't show it after failed (ambiguous) type inference.
* Always set reasonable variable type after failed inference (like `List[Any]` for an empty list).
* Always give `Need type annotation for variable` error, 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())` returns `True` for everything, including `UninhabitedType`. I would say we should actually avoid leaking unbound types from semantic analysis and replace the, with `Any`, but this is a separate issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants