-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Beta rollups #58656
Beta rollups #58656
Conversation
…dence over an ICE.
|
|
(Why did highfive comment twice?) |
@bors r+ p=50
That's a good question, I'll start looking for a good answer! |
📌 Commit dc9daa4557a874a3e9df5d859f854bb29da84dfc has been approved by |
⌛ Testing commit dc9daa4557a874a3e9df5d859f854bb29da84dfc with merge 864a406f8d1eb4ba874b23df7e4e67f901a75378... |
💔 Test failed - checks-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Discussed on Zulip, will back out the PR that introduced this test: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/beta.20backports |
In our type inference system, when we "generalize" a type T to become a suitable value for a type variable V, we sometimes wind up creating new inference variables. So, for example, if we are making V be some subtype of `&'X u32`, then we might instantiate V with `&'Y u32`. This generalized type is then related `&'Y u32 <: &'X u32`, resulting in a region constriant `'Y: 'X`. Previously, however, we were making these fresh variables like `'Y` in the "current universe", but they should be created in the universe of V. Moreover, we sometimes cheat in an invariant context and avoid creating fresh variables if we know the result must be equal -- we can only do that when the universes work out.
This set of diffs was produced by combing through b68fad6 and seeing where the `leak_check` used to be invoked and how.
One surprise: old-lub-glb-object.rs, may indicate a bug
This preserves the error you currently get on stable for the old-lub-glb-object.rs test.
Incorporates a bunch of the documentation-related comments that came up when discussing `Pin` stabilization.
Cherry-picked (and squashed) from rust-lang#58227.
dc9daa4
to
5c6eb4e
Compare
@bors r=pietroalbini |
📌 Commit 5c6eb4e has been approved by |
☀️ Test successful - checks-travis, status-appveyor |
A few of these are via #58641.
r? @pietroalbini