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

Use impl obligations as initial environment for specialization #37541

Merged
merged 3 commits into from
Nov 3, 2016

Conversation

nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Nov 2, 2016

This corrects a small regression in specialization that crept in, I think as part of the refactoring to introduce arenas. I also made an experiment (in the last commit) to cleanup the code to be more aggressive about normalization. As the commit log notes, I am not 100% sure that this is correct, but it feels safer, and I think that at worst it yields more ICEs (as opposed to admitting faulty code). I'll schedule a crater run to check beyond the testbase.

Fixes #37291.

r? @aturon

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Nov 2, 2016

This fixes a regression. Backport? Perhaps best would be to backport a less aggressive version (basically drop the 3rd commit).

cc @rust-lang/compiler

@nikomatsakis nikomatsakis added beta-nominated Nominated for backporting to the compiler in the beta channel. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 2, 2016
The `specializes()` function was trying to normalize the impl trait in
an empty environment. This could lead to inexplicable failures.
This seems better because I want to avoid the situation where unresolved
inference variables make it into the environment.  On the other hand, I
am not 100% sure that this is correct. My assumption was that the WF
check should ensure that this normalization can succeed. But it occurs
to me that the WF checks may need to make use of the `specializes`
predicate themselves, and hence we may have a kind of cycle here (this
is a bigger problem with spec in any case that we need to resolve).

On the other hand, this should just cause extra errors I think, so it
seems like a safe thing to attempt. Certainly all tests pass.
@brson
Copy link
Contributor

brson commented Nov 3, 2016

@bors r+ p=1 (need to get backports done)

@bors
Copy link
Contributor

bors commented Nov 3, 2016

📌 Commit b4f910d has been approved by brson

@brson brson mentioned this pull request Nov 3, 2016
@bors
Copy link
Contributor

bors commented Nov 3, 2016

⌛ Testing commit b4f910d with merge ac919fc...

bors added a commit that referenced this pull request Nov 3, 2016
Use impl obligations as initial environment for specialization

This corrects a small regression in specialization that crept in, I think as part of the refactoring to introduce arenas. I also made an experiment (in the last commit) to cleanup the code to be more aggressive about normalization. As the commit log notes, I am not 100% sure that this is correct, but it feels safer, and I think that at worst it yields *more* ICEs (as opposed to admitting faulty code). I'll schedule a crater run to check beyond the testbase.

Fixes #37291.

r? @aturon
@bors bors merged commit b4f910d into rust-lang:master Nov 3, 2016
@nikomatsakis nikomatsakis added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Nov 3, 2016
@nikomatsakis
Copy link
Contributor Author

Approving for backport w/o the 3rd commit, which is a bit more conservative. The first part is definitely wrong and this fixes a regression.

cc @rust-lang/compiler

@brson brson removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Nov 3, 2016
@nikomatsakis nikomatsakis deleted the issue-37291 branch April 14, 2017 10:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants