Skip to content

Make bottom type fallback lazy #22010

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

edwardw
Copy link
Contributor

@edwardw edwardw commented Feb 6, 2015

PR #17603 introduced bottom type fallback but did it a bit too
eagerly. This patch makes the fallback lazy so that typeck can run
its cause and detect as many type errors as possible with regard to
diverging types.

Closes #21878

PR rust-lang#17603 introduced bottom type fallback but did it a bit too
eagerly. This patch makes the fallback lazy so that `typeck` can run
its cause and detect as many type errors as possible with regard to
diverging types.

Closes rust-lang#21878
@rust-highfive
Copy link
Contributor

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member

cc @nikomatsakis

@edwardw
Copy link
Contributor Author

edwardw commented Feb 13, 2015

r? @nikomatsakis

@rust-highfive rust-highfive assigned nikomatsakis and unassigned Aatch Feb 13, 2015
@nikomatsakis
Copy link
Contributor

Hmm, I'm not sure how I feel about this. This introduces a "second kind" of fallback. I was planning to start work soon on RFC rust-lang/rfcs#213, which would generalize fallback for integer literals to other type parameters, and part of the reason I felt ok with ! falling back to () was that it would fit into this general framework. But then again perhaps it is best to make it special -- I agree that the examples from #21878 are unfortunate. And this change seems pretty reasonable overall. (Have you done any experiments to see how much code breaks if we just remove ! fallback?)

@edwardw
Copy link
Contributor Author

edwardw commented Feb 13, 2015

I just did a quick experiment of removing ! fallback altogether. It failed right away at libcore/num/mod.rs with an error saying "cannot determine a type for this expression: unconstrained type".

@edwardw
Copy link
Contributor Author

edwardw commented Feb 13, 2015

And of course, feel free to close this PR if you have something more general in the making.

@nikomatsakis
Copy link
Contributor

@edwardw well what I had in mind is kind of orthogonal to what you've done here. I'm still tossing it about in my mind.

@steveklabnik
Copy link
Member

@nikomatsakis what's your thoughts on this today?

@bors
Copy link
Collaborator

bors commented Jun 12, 2015

☔ The latest upstream changes (presumably #26232) made this pull request unmergeable. Please resolve the merge conflicts.

@edwardw edwardw closed this Jun 13, 2015
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Type ambiguity not reported when it may exist?
7 participants