enable mir inlining across trait methods

[nikomatsakis]

As the fix to #40473, @qmx disabled MIR inlining of trait calls altogether. This issue tracks the task of re-enabling the inlining, where possible! This is a slightly more involved task.

Here is the example text:

pub trait Foo {
    fn bar(&self) {}
}

impl Foo for () {
    fn bar(&self) { println!("Hello, World!"); }
}

pub fn main() {
    ().bar();
}

The goal would be to have the call to bar() inlined. But we should draw up some more interesting tasks showing edge-cases: for example, generic functions and so forth (we should be able to use RevealMode::All to "see through" specialization, since inlining executes quite late).

I think roughly speaking the steps to solve this issue "properly" are to:

• Refactor Instance and InstanceDef out of librustc_trans and (probably) into librustc
• Rework inlining to use those mechanisms to resolve method calls (including trait ones)

[nikomatsakis]

Some notes:

First, this code in the lints does more or less what is needed already (in particular, this match arm is the case where we are able to find a particular impl).

Second, the code in trans is reasonable, but assumes that things are monomorphized (otherwise it has to return an Option, to start). The heart of that code, in any case, is the call to the helper function trans_fulfill_obligation(), which actually lives in librustc already.

To be quite honest i'm not entirely sure what the "right abstraction" looks like here. It's not clear to me that using Instance in this particular case would add a lot of value at this point in time -- but I suppose that, longer term, it might be a stepping stone to letting us generalize the inlining code even further, so that it can (e.g.) inline bits of drop glue or other things that are not user-defined functions.

I also know that we've talked for some time about migrating some of the "trans" logic out of librustc_trans, since things like miri etc -- not to mention other potential optimizations and backends -- will want to make use of it. I know that @eddyb had some thoughts -- perhaps he can leave some notes as to what he would like to see!

[eddyb]

This is the true entrypoint:

rust/src/librustc_trans/monomorphize.rs

Line 166 in d7d75ef

pub fn resolve<'a, 'tcx>(

This should be in librustc and everyone should use it. That's pretty much it.
There's enough functionality in there to work without monomorphization, including taking specialization into account to not resolve more aggressively than it's sound to, it just has to return Option/Result like @nikomatsakis mentioned, instead of panicking.