Propagate container across object cast

[pnkfelix]

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 #22006 for examples of such fallout, much of which will be unnecessary with this fix.

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[pnkfelix]

cc @nikomatsakis

[eddyb]

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.

[pnkfelix]

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...)

[eddyb]

r=me with the test additions.

[pnkfelix]

@bors: r=eddyb a1b3189 rollup

[nrc]

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 x as Box<Foo> is essentially compiled as (x: Box<Foo>) as Box<Foo>. The solution is to re-implement this patch for coercions, but I'm not sure if that is possible because coercions are a little less 'directed' by the types involved.

[nrc]

ping @pnkfelix about that last comment

[pnkfelix]

@nrc when you say "so x as Box is essentially compiled as (x: Box<Foo>) as Box<Foo>", you mean that is what you do on your branch?

If so, then I think that should be fine; the important thing was getting the type-hint that x has some Box<_> type, at least for my purposes.

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)pubfncoerce<'a,F>(f:F) -> BoxFn<'a>whereF:Fn(),F:'a{box_!( f )asBoxFn}

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.

[pnkfelix]

@nrc and I discussed further; I was over-optimistic when I said:

If so, then I think that should be fine

because what I would have really liked would be to compile x as Box<Foo> into (x: Box<_>) as Box<Foo> (and not(x: Box<Foo> as Box<Foo>))

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.