Skip to content

[SR-176] Skip type checking case patterns when switch is error type. #432

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

Merged
merged 1 commit into from
Dec 18, 2015

Conversation

gregomni
Copy link
Contributor

This stops emitting unhelpful diagnostics about “<>” (as in
SR-176) while still complaining about the switch itself and any other
errors in case bodies.

@lattner
Copy link
Contributor

lattner commented Dec 11, 2015

I will take a look at this in more detail this evening, but should coercePatternToType itself handle the errortype case? What behavior do other callers expect?

@lattner lattner self-assigned this Dec 11, 2015
@gregomni
Copy link
Contributor Author

Other callers:

For closure argument patterns, this only gets called after the closure's function type itself has been determined, and if any of the args were errortype, the closure would be errortype instead of a function type.

For exception catch patterns, this only gets called with the built in exception type.

For a for-each pattern, this only gets called during a BindingListener::appliedSolution(), which (I think) can only happen if all of the type constraints successfully bound to real types.

In short, it ought to be fine (just via inspection, haven't run tests or anything yet) to move this check in as a precondition inside coercePatternToType() if that seems like a better place for it, since no other callers will ever call it with that type.

@lattner
Copy link
Contributor

lattner commented Dec 11, 2015

If it will work, merging it into coercePatternToType sounds better to me, thanks!

@gregomni
Copy link
Contributor Author

Turns out I was wrong in my inspection: The TypeChecker can call coercePatternToType() via typeCheckPattern() with an errortype while it is checking closure params, and it depends upon the side-effect of the types of those params being set to errortype as a result, among other things.

So to get the same result of supressing the bad diagnoses, the checks for errortype need to be in specific cases inside coercePatternToType() instead of a blanket precondition. Added a second commit that does that.

@lattner
Copy link
Contributor

lattner commented Dec 17, 2015

i'm sorry for losing track of this patch. The patch looks good to me, but I can't accept the PR because there is a silly conflict (someone renamed element to elt in TypeCheckPattern.cpp. Please update the patch and I'll be happy to accept it, thank you for fixing this!

This stops emitting unhelpful diagnostics about “<<error type>>” (as in
SR-176) while still complaining about the switch itself and any other
errors in case bodies.
@gregomni
Copy link
Contributor Author

It's not like you have anything else to do or anything, sheesh! 😀 Rebased off the base branch and merged/squashed. Hopefully good now (tests all still pass, github says there are no conflicts).

lattner added a commit that referenced this pull request Dec 18, 2015
[SR-176] Skip type checking case patterns when switch is error type.
@lattner lattner merged commit 02971fb into swiftlang:master Dec 18, 2015
@lattner
Copy link
Contributor

lattner commented Dec 18, 2015

Fantastic, thank you again for fixing this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants