Propagate container across object cast #22012
Conversation
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
| impl Foo for u32 { fn foo(&self) -> u32 { *self } } | ||
|
|
||
| trait Boxed { fn make() -> Self; } | ||
| impl Boxed for Box<u32> { fn make() -> Self { Box::new(7) } } |
There was a problem hiding this comment.
Could you add a second impl that returns something which is not Box<_>? (same for Refed below)
I recall being bit before by having just one impl and getting it selected even without enough type hints.
There was a problem hiding this comment.
Will do. (Its interesting, @alexcrichton brought up the same issue on the RFC itself. I wonder if this is an artifact of the old trait matching code, or the new, or both...)
|
r=me with the test additions. |
pnkfelix
force-pushed
the
propagate-container-across-object-cast
branch
from
ca73b6f
to
ee87aa1
Compare
(with multiple impls to further exercise correct trait-matching.)
pnkfelix
force-pushed
the
propagate-container-across-object-cast
branch
from
ee87aa1
to
a1b3189
Compare
…-object-cast, r=eddyb Given `<expr> as Box<Trait>`, infer that `Box<_>` is expected type for `<expr>`.
…object-cast Given `<expr> as Box<Trait>`, infer that `Box<_>` is expected type for `<expr>`. This is useful for addressing fallout from newly proposed box protocol; see rust-lang#22006 for examples of such fallout, much of which will be unnecessary with this fix.
…using `fresh_ty` (hat tip to nikomatsakis who was the one who pointed out this simplification to the logic.)
PR #22012 followup: clean up vtable::check_object_cast by reusing `fresh_ty` (hat tip to nikomatsakis, who was the one who pointed out this simplification to the logic.)
|
Are we going to miss this? I have a branch which removes this facility. The root problem is that we do object conversions differently depending on if we are using coercion or casting. My branch removes the cast code path completely so |
|
ping @pnkfelix about that last comment |
|
@nrc when you say "so x as Box is essentially compiled as If so, then I think that should be fine; the important thing was getting the type-hint that If you look at appendix b from the most recent box/placement RFC, it shows the particular place where I needed this PR, namely the bit that says: #[cfg(coerce_works3)] // (This one assumes PR 22012 has landed)
pub fn coerce<'a, F>(f: F) -> BoxFn<'a> where F: Fn(), F: 'a { box_!( f ) as BoxFn }so you should be able to take that code, put it into a file, and try your branch on it, to make sure you don't regress the behavior here. (I guess I should have maybe put in some tests to ensure this did not get regressed.) In other words, make sure that this playpen does not stop working, and I'll be happy. |
|
@nrc and I discussed further; I was over-optimistic when I said:
because what I would have really liked would be to compile but in any case, after further discussion I decided that its not the end of the world if @nrc makes the change he desires here. |
Given
<expr> as Box<Trait>, infer thatBox<_>is expected type for<expr>.This is useful for addressing fallout from newly proposed box protocol; see #22006 for examples of such fallout, much of which will be unnecessary with this fix.