-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Remove TraitStore from ty_trait #14869
Conversation
Interesting test failure... |
let bounds = parse_bounds(st, |x,y| conv(x,y)); | ||
assert_eq!(next(st), ']'); | ||
return ty::mk_trait(st.tcx, def, substs, store, bounds.builtin_bounds); | ||
return ty::mk_trait(st.tcx, def, substs, bounds.builtin_bounds); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two spaces between substs
and bounds.builtin_bounds
. This might show up in other places, too.
r? anyone? |
Wut? That doesn't happen locally :-( |
/me will read |
// FIXME(12470) If we have mutable references to trait objects, we | ||
// used to use covariant subtyping. I have preserved this behaviour, | ||
// even though it is probably incorrect. So don't go down the usual | ||
// path which would require invariance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about this lately, as we briefly discussed on the phone. On the one hand, there are rules against assigning lvalues of unsigned type, so in fact an &mut U
(where U
is unsized) is more limited than an &mut S
(where S
is sized). In particular, you cannot do *x = foo as Trait
or something like that. For this reason, I believe that e.g. &mut (Trait1+Trait2) <: &mut Trait1
is sound, though I want to consider it more deeply. Nonetheless, I am not happy about the rules for &mut T
considering whether T
is sized.
I am not convinced this is related to #12470 -- can you open a separate bug perhaps to settle variance w/r/t DST and &mut
more definitively?
Also, I presume that when you didn't have this code, various things broke?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, at first I thought this was sound too. I couldn't come up with a counter-example. So now I'm not sure.
#12470 is about enforcing invariance here for lifetimes, whereas this is about enforcing invariance for bounds. I'll open a new bug for issue.
Yep, stuff broke. Not sure how much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed #14985
Use ty_rptr/ty_uniq(ty_trait) rather than TraitStore to represent trait types. Also addresses (but doesn't close) rust-lang#12470. Part of the work towards DST (rust-lang#12938). [breaking-change] lifetime parameters in `&mut trait` are now invariant. They used to be contravariant.
The rust-lang#14869 removed `TraitStore` from `ty_trait` and represented trait reference as regular `ty_rptr`. An old bug of the missing constraint upon lifetime parameter of trait reference then is fixed as a side effect. Adds tests for affected bugs and closes them. Closes rust-lang#12470. Closes rust-lang#14285.
The rust-lang#14869 removed `TraitStore` from `ty_trait` and represented trait reference as regular `ty_rptr`. An old bug of the missing constraint upon lifetime parameter of trait reference then is fixed as a side effect. Adds tests for affected bugs and closes them. Closes rust-lang#12470. Closes rust-lang#14285.
Use ty_rptr/ty_uniq(ty_trait) rather than TraitStore to represent trait types.
Also addresses (but doesn't close) #12470.
Part of the work towards DST (#12938).