Skip to content

Support type aliases in fine-grained incremental mode #4394

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

Closed
JukkaL opened this issue Dec 19, 2017 · 3 comments
Closed

Support type aliases in fine-grained incremental mode #4394

JukkaL opened this issue Dec 19, 2017 · 3 comments

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Dec 19, 2017

This includes generic type aliases such as X = Dict[str, T] and aliases to all kinds of types.

Generating dependencies may be tricky.

@msullivan
Copy link
Collaborator

Here is a test case for it that fails:

[case testAliasUpdate]
import b
[file a.py]
N = int
x = 1
[file a.py.2]
N = str
x = 'hi'
[file b.py]
import a
def f(x: a.N) -> None:
    pass
f(a.x)
[out]
==

@JukkaL
Copy link
Collaborator Author

JukkaL commented Jan 26, 2018

The challenge here is that type aliases are completely replaced during semantic analysis, and thus we can't easily determine which type aliases were used after the fact. Here are two approaches for resolving this:

  1. Create a new type for type alias references that doesn't get simplified away during semantic analysis.
  2. Collect all expanded type aliases during semantic analysis and store them so that they can be used in dependency generation. For example, collect a dictionary from target to set of type aliases used.

The first approach would likely require pretty major changes to mypy, since each Type object might need to be dereferenced to get the actual effective type. I prefer the second approach due to its simplicity, though it's a little hacky.

@ilevkivskyi
Copy link
Member

There is a related issue #4082, but I think these two are independent. The other issue is about having it clear in the symbol table (not via type_override and other hacks), but the question about what to do about expanded types is different. I agree that option 2 is a bit hacky, but we did conceptually similar thing for forward references and it seems to work well. So I am fine with option 2 (also it is easy to implement).

@ilevkivskyi ilevkivskyi self-assigned this Jan 26, 2018
ilevkivskyi added a commit that referenced this issue Feb 21, 2018
Fixes #4394

This covers all common cases and majority of corner cases:
*Simple aliases
*Generic aliases
*Forward references
*Nested aliases
*Chained aliases
* Special forms

Note that among tests added some also pass without this addition
(probably because some dependencies are added by coincidence).
Note that I mainly focus on false negatives, since in my experience
while playing with fine-grained daemon, this is the most typical
problem.
yedpodtrzitko pushed a commit to kiwicom/mypy that referenced this issue Mar 15, 2018
Fixes python#4394

This covers all common cases and majority of corner cases:
*Simple aliases
*Generic aliases
*Forward references
*Nested aliases
*Chained aliases
* Special forms

Note that among tests added some also pass without this addition
(probably because some dependencies are added by coincidence).
Note that I mainly focus on false negatives, since in my experience
while playing with fine-grained daemon, this is the most typical
problem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants