Skip to content
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

Remove region variable leaks from higher_ranked_sub(). #28369

Merged
merged 2 commits into from
Sep 22, 2015

Conversation

ebfull
Copy link
Contributor

@ebfull ebfull commented Sep 12, 2015

Fixes #28279.

Currently

common_supertype(*mut for<'a> Fn(&'a usize), *mut for<'a> Fn(&'a usize) + 'static)

equals *mut Fn(&usize) which seems to be caused by higher_ranked_sub() allowing region variables to escape the comparison. This prevents inference from working properly with stuff like Rc<Fn(&T)>.

r? @nikomatsakis

@ebfull
Copy link
Contributor Author

ebfull commented Sep 13, 2015

This could be better with tests to make sure that the tainted region checks are sound, but I can't come up with any.

@nikomatsakis
Copy link
Contributor

Actually, the return value from sub (and equate) ought to be ignored, as described...well, somewhere or other. I think the bug is in the relate_with_variance for lub etc. That said, it is probably wrong to return result here. It would be better to return a (which is also consistent with what the other sub cases do). That would probably fix lub, fwiw, but it still seems like it's wrong to return the result from equate. I guess it'd be better to say that sub always returns a subtype (i.e., a), if it does not yield an error. I don't think that introduces any particular difficulties to do. Similarly, equate can be defined to return a something that is equal.

@ebfull
Copy link
Contributor Author

ebfull commented Sep 15, 2015

Nice, that makes much more sense. I've rebased with a much more conservative fix that covers most of the bases. If you think I should go through and return a from all of the pertinent routines (such as higher_ranked_sub etc.) I can do that too.

@nikomatsakis
Copy link
Contributor

@ebfull it seems like the policy is a bit unclear; I think at least a comment on Sub and Equate indicating that they are supposed to:

  • make a a subtype of (resp. equal to) b
  • return a

would make the policy clear.

@brson
Copy link
Contributor

brson commented Sep 22, 2015

I've started a crater run.

@nikomatsakis
Copy link
Contributor

@ebfull ah, I see you pushed a commit, sorry, I didn't notice (GH doesn't notify me). This looks good to me. @brson, is there any particular reason you started a crater run for this branch? (I wouldn't expect regressions from it in particular...?)

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Sep 22, 2015

📌 Commit e567cb5 has been approved by nikomatsakis

@bors
Copy link
Collaborator

bors commented Sep 22, 2015

⌛ Testing commit e567cb5 with merge ecbd8c3...

bors added a commit that referenced this pull request Sep 22, 2015
Fixes #28279.

Currently

`common_supertype(*mut for<'a> Fn(&'a usize), *mut for<'a> Fn(&'a usize) + 'static)`

equals `*mut Fn(&usize)` which seems to be caused by `higher_ranked_sub()` allowing region variables to escape the comparison. This prevents inference from working properly with stuff like `Rc<Fn(&T)>`.

r? @nikomatsakis
@ebfull
Copy link
Contributor Author

ebfull commented Sep 22, 2015

@nikomatsakis I asked @brson if it would be a good idea, in case it fixes soundness holes we weren't aware of. I apologize if this was an unnecessary use of crater resources.

@nikomatsakis
Copy link
Contributor

@ebfull oh not to worry, I just wondered if there was some known interaction

@bors bors merged commit e567cb5 into rust-lang:master Sep 22, 2015
@brson
Copy link
Contributor

brson commented Sep 28, 2015

Oh, shoot, sorry I let this crater run slip. It's still in progress.

@brson
Copy link
Contributor

brson commented Sep 29, 2015

I've been running into problems with crater. Still trying to get this through.

@brson
Copy link
Contributor

brson commented Sep 30, 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.

4 participants