extend simplify_type

[lcnr]

might cause a slight perf inprovement and imo more accurately represents what types there are.

considering that I was going to use this in #85048 it seems like we might need this in the future anyways 🤷

[rust-highfive]

r? @LeSeulArtichaut

(rust-highfive has picked a reviewer for you, use r? to override)

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 45273f8187cea4bdd13b5381f00b5fbce354f22b with merge 42b0078198bdfc32d8c25b4bac110afe8785e596...

[LeSeulArtichaut]

I'm not the right reviewer. Looks like you wanted to assign #85048 to @nikomatsakis, should I r? him?

[bors]

☀️ Try build successful - checks-actions
Build commit: 42b0078198bdfc32d8c25b4bac110afe8785e596 (42b0078198bdfc32d8c25b4bac110afe8785e596)

[rust-timer]

Queued 42b0078198bdfc32d8c25b4bac110afe8785e596 with parent aa65b08, future comparison URL.

[lcnr]

r? @nikomatsakis

[rust-timer]

Finished benchmarking try commit (42b0078198bdfc32d8c25b4bac110afe8785e596): comparison url.

Summary: This change led to significant mixed results 🤷 in compiler performance.

• Large regression in instruction counts (up to 9.2% on incr-patched: sparse set builds of regex-check)
• Moderate improvement in instruction counts (up to -2.4% on full builds of futures-check)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

[lcnr]

while CI is failing here, I am not able to reproduce this locally 🤔 has someone an idea why that might be?

[nikomatsakis]

@lcnr I'm rather surprised by the 9% regression! It seems like these changes make the "fast reject" more precise without introducing significantly more work, and that seems like it can only be helpful. Do you have any idea what I'm missing here?

[lcnr]

@bors try @rust-timer queue

@oli-obk found one case where we end up doing more work. Before that I wasn't sure why we had to rerun more queries with this PR, but tbh i didn't bother as I considered the impact to be negligible. Let's see if this fixes that

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[lcnr]

@nikomatsakis does this comment make sense to you? I hoped to trigger it by using something like the following, but wasn't able to make much progress. We either normalize the projection because it is already concrete enough or fail for some different reason. Not sure if this is actually exploitable if it even is an issue.

trait Id {
    type Assoc;
}

impl<T> Id for T {
    type Assoc = Self;
}

trait Bar<T> {
    type Assoc;
    fn bar(self) -> Self::Assoc; 
}

impl Bar<u32> for i32 {
    type Assoc = i32;
    fn bar(self) -> Self::Assoc {
        1
    }
}

fn main() {
    let mut x = <<_ as Id>::Assoc>::default();
    x = <_ as Bar<u32>>::bar(x);
}

[bors]

☔ The latest upstream changes (presumably #91354) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #91549) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

@bors r=nikomatsakis,oli-obk

[bors]

📌 Commit 00cbacb has been approved by nikomatsakis,oli-obk

[bors]

⌛ Testing commit 00cbacb with merge 69ac533...

[bors]

☀️ Test successful - checks-actions
Approved by: nikomatsakis,oli-obk
Pushing 69ac533 to master...

[rust-timer]

Finished benchmarking commit (69ac533): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

• Large improvement in instruction counts (up to -4.7% on full builds of hyper-2)
• Very large regression in instruction counts (up to 8.4% on incr-patched: sparse set builds of regex)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[lcnr]

the only regressions are small changes to some incr-patched tests, so this does seem like a strict perf improvement to me

[oli-obk]

@rustbot label: +perf-regression-triaged