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

Fixes to tuple fallbacks #6442

Merged
merged 17 commits into from Feb 22, 2019

Conversation

Projects
None yet
2 participants
@JukkaL
Copy link
Collaborator

commented Feb 20, 2019

This changes tuple fallbacks to be calculated on demand during
type checking. This fixes some issues with fallbacks being imprecise.

In the new semantic analyzer, this introduces a new pass just after
the main semantic analysis pass to calculate precise item types for
tuple base classes. These can't be calculated on demand since
the base class is a variable-length tuple type (Instance) instead
of TupleType. We can't calculate these during the main semantic
analysis pass since base classes can be incomplete.

Fixes #6400.

@JukkaL JukkaL requested a review from ilevkivskyi Feb 20, 2019

@ilevkivskyi
Copy link
Collaborator

left a comment

Looks good! This is a large piece of work. I have few comments and suggestions.

@@ -2785,7 +2787,7 @@ def visit_tuple_expr(self, e: TupleExpr) -> Type:
tt = self.accept(item, type_context_items[j])
j += 1
items.append(tt)
fallback_item = join.join_type_list(items)
fallback_item = AnyType(TypeOfAny.special_form)

This comment has been minimized.

Copy link
@ilevkivskyi

ilevkivskyi Feb 21, 2019

Collaborator

Maybe add a comment above reminding that this is just a partial fallback, and a real fallback is always calculated on-demand.

@@ -19,12 +20,8 @@
# Priorities for ordering of patches within the final "patch" phase of semantic analysis
# (after pass 3):

This comment has been minimized.

Copy link
@ilevkivskyi

ilevkivskyi Feb 21, 2019

Collaborator

There is no pass three anymore, so this comment can also be updated.

This must be called only after the main semantic analysis pass, since joins
aren't available before that.
"""

This comment has been minimized.

Copy link
@ilevkivskyi

ilevkivskyi Feb 21, 2019

Collaborator

I would mention the chicken and egg problem about tuple fallbacks and checking upper bounds for instances here, and/or maybe in a comment in semanal_main() where the two are called.

class C(A): pass

class T(Tuple[B, C]):
pass

This comment has been minimized.

Copy link
@ilevkivskyi

ilevkivskyi Feb 21, 2019

Collaborator

Maybe put the classes in reverse order (just to check that forward refs also work, although I am quite they should).


class NTStr(NamedTuple):
x: str
y: str

This comment has been minimized.

Copy link
@ilevkivskyi

ilevkivskyi Feb 21, 2019

Collaborator

I would add couple non-trivial upper bound checks, just be sure they behave reasonably with the current ordering (fallbacks first, then bounds).

for nx in nt:
reveal_type(nx) # E: Revealed type is 'Union[builtins.int*, builtins.str*]'

t: Union[Tuple[int, int], Tuple[str, str]]
for x in t:
# TODO(Ivan): This will be OK when tuple fallback patches are added (like above)
reveal_type(x) # E: Revealed type is 'Any'

This comment has been minimized.

Copy link
@ilevkivskyi

ilevkivskyi Feb 21, 2019

Collaborator

There is also an issue about this on tracker #3575. Also there is a chance that #5393 will be fixed by this PR. Should we close issues when they are fixed in the new analyzer?

@@ -204,6 +217,11 @@ def semantic_analyze_target(target: str,
return [], analyzer.incomplete


def process_patches(graph: 'Graph', scc: List[str]) -> None:
for module in scc:
graph[module].semantic_analysis_apply_patches()

This comment has been minimized.

Copy link
@ilevkivskyi

ilevkivskyi Feb 21, 2019

Collaborator

I would add a motivational docstring explaining why we do mini-passes for one things, and patches for other. My understanding that there will be quite few tuple types in a typical program, but quite a lot instances, so we a make a traverser for the latter.

Also there is an option to combine these two in a single type fixing traverser pass, and then repeat it until we solved the chicken and egg problem (this would require to somehow mark types as ready). I however didn't think much about this, maybe this will not help.

JukkaL added some commits Feb 22, 2019

@JukkaL JukkaL merged commit 2bc14eb into master Feb 22, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@ethanhs ethanhs deleted the semanal-tuple-2 branch Feb 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.