normalize substs while inlining

[lcnr]

fixes #68347 or more precisely, this fixes the same ICE in rust analyser as veloren is pinned to a specific nightly
and had an error with the current one.

I didn't look into creating an MVCE here as that seems fairly annoying, will spend a few minutes doing so rn. (failed)

r? @eddyb cc @bjorn3

[eddyb]

Hmm, this might be expensive. What I would do is assert that normalizing doesn't change the type, then track down the source of the unnormalized type and fix that. But just to see what impact it has on its own:

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 9221cff8dd27d91159a85a5be10de376d4dd6df1 with merge 9f6cf14e9aa588419e60b7f07767d8d81befe061...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 9f6cf14e9aa588419e60b7f07767d8d81befe061 (9f6cf14e9aa588419e60b7f07767d8d81befe061)

[rust-timer]

Queued 9f6cf14e9aa588419e60b7f07767d8d81befe061 with parent fc2daaa, future comparison URL.

[rust-timer]

Finished benchmarking try commit (9f6cf14e9aa588419e60b7f07767d8d81befe061): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[eddyb]

LGTM but r? @nikomatsakis or @matthewjasper (this feels like a matter of policy, i.e. fixing normalization bugs or working around them with aggressive normalization elsewhere, like in this PR).

[lcnr]

will spend a bit of time looking at where we fail to normalize this week to fix his bug at its origin

[nikomatsakis]

The change itself seems harmless. I am of two minds about whether this sort of workaround is acceptable. In general I prefer to normalize at the source but I also feel like being pragmatic may make sense. It's too bad there is no test here but I see that @lcnr already tried to create one and failed.

[nikomatsakis]

I guess I would say that if some effort at investigation fails, I am inclined to r+

[lcnr]

Minimization

pub fn write() {
    create()()
}

pub fn create() -> impl FnOnce() {
   || ()
}

edit: this minimization doesn't actually cause an ICE on nightly but does cause one with the debug assert in codegen_fulfill_obligation.

[eddyb]

@bors r+ Thanks!

[bors]

📌 Commit 73424ec396b743a8ca6ae74702ba1b9bcdce6919 has been approved by eddyb

[lqd]

Here's a reduction of the veloren error:

pub fn main() {
    let _x: fn() = handle_debug_column;
}

fn handle_debug_column() {
    let sampler = sample_columns();

    let foo = || {
        sampler.get(17);
    };
    foo();
}

fn sample_columns() -> impl Sampler {
    ColumnGen {}
}

struct ColumnGen {}

trait Sampler {
    fn get(&self, index: i32);
}

impl Sampler for ColumnGen {
    fn get(&self, _index: i32) {}
}

[lcnr]

added the test by @lqd

@bors r=eddyb

[bors]

📌 Commit 1f74e0b24f4bb64ad52b5addcc53654c56a8323f has been approved by eddyb

[bors]

⌛ Testing commit 1f74e0b24f4bb64ad52b5addcc53654c56a8323f with merge 96640e765bbab1ba6d7e0095b6d68a4af10a06fc...

[bors]

💔 Test failed - checks-actions

[eddyb]

@bors r+

[bors]

📌 Commit ac893b8 has been approved by eddyb

[bors]

⌛ Testing commit ac893b8 with merge 4d247ad...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: eddyb
Pushing 4d247ad to master...

[rust-highfive]

📣 Toolstate changed by #77306!

Tested on commit 4d247ad.
Direct link to PR: #77306

💔 rls on windows: test-pass → build-fail (cc @Xanewok).
💔 rls on linux: test-pass → build-fail (cc @Xanewok).
💔 rustfmt on windows: test-pass → build-fail (cc @topecongiro @calebcartwright).
💔 rustfmt on linux: test-pass → build-fail (cc @topecongiro @calebcartwright).