cache types during normalization

[lcnr]

partially fixes#75992

reduces the following test from 14 to 3 seconds locally.

cc @Mark-Simulacrum would it make sense to add that test to perf?

#![recursion_limit="2048"]#![type_length_limit="112457564"]pubasyncfnh0(v:&String,x:&u64){println!("{} {}", v, x)}pubasyncfnh1(v:&String,x:&u64){h0(v, x).await}pubasyncfnh2(v:&String,x:&u64){h1(v, x).await}pubasyncfnh3(v:&String,x:&u64){h2(v, x).await}pubasyncfnh4(v:&String,x:&u64){h3(v, x).await}pubasyncfnh5(v:&String,x:&u64){h4(v, x).await}pubasyncfnh6(v:&String,x:&u64){h5(v, x).await}pubasyncfnh7(v:&String,x:&u64){h6(v, x).await}pubasyncfnh8(v:&String,x:&u64){h7(v, x).await}pubasyncfnh9(v:&String,x:&u64){h8(v, x).await}pubasyncfnh10(v:&String,x:&u64){h9(v, x).await}pubasyncfnh11(v:&String,x:&u64){h10(v, x).await}pubasyncfnh12(v:&String,x:&u64){h11(v, x).await}pubasyncfnh13(v:&String,x:&u64){h12(v, x).await}pubasyncfnh14(v:&String,x:&u64){h13(v, x).await}pubasyncfnh15(v:&String,x:&u64){h14(v, x).await}pubasyncfnh16(v:&String,x:&u64){h15(v, x).await}pubasyncfnh17(v:&String,x:&u64){h16(v, x).await}pubasyncfnh18(v:&String,x:&u64){h17(v, x).await}pubasyncfnh19(v:&String,x:&u64){h18(v, x).await}macro_rules! async_recursive {(29, $inner:expr) => {async{ async_recursive!(28, $inner)}.await};(28, $inner:expr) => {async{ async_recursive!(27, $inner)}.await};(27, $inner:expr) => {async{ async_recursive!(26, $inner)}.await};(26, $inner:expr) => {async{ async_recursive!(25, $inner)}.await};(25, $inner:expr) => {async{ async_recursive!(24, $inner)}.await};(24, $inner:expr) => {async{ async_recursive!(23, $inner)}.await};(23, $inner:expr) => {async{ async_recursive!(22, $inner)}.await};(22, $inner:expr) => {async{ async_recursive!(21, $inner)}.await};(21, $inner:expr) => {async{ async_recursive!(20, $inner)}.await};(20, $inner:expr) => {async{ async_recursive!(19, $inner)}.await};(19, $inner:expr) => {async{ async_recursive!(18, $inner)}.await};(18, $inner:expr) => {async{ async_recursive!(17, $inner)}.await};(17, $inner:expr) => {async{ async_recursive!(16, $inner)}.await};(16, $inner:expr) => {async{ async_recursive!(15, $inner)}.await};(15, $inner:expr) => {async{ async_recursive!(14, $inner)}.await};(14, $inner:expr) => {async{ async_recursive!(13, $inner)}.await};(13, $inner:expr) => {async{ async_recursive!(12, $inner)}.await};(12, $inner:expr) => {async{ async_recursive!(11, $inner)}.await};(11, $inner:expr) => {async{ async_recursive!(10, $inner)}.await};(10, $inner:expr) => {async{ async_recursive!(9, $inner)}.await};(9, $inner:expr) => {async{ async_recursive!(8, $inner)}.await};(8, $inner:expr) => {async{ async_recursive!(7, $inner)}.await};(7, $inner:expr) => {async{ async_recursive!(6, $inner)}.await};(6, $inner:expr) => {async{ async_recursive!(5, $inner)}.await};(5, $inner:expr) => {async{ async_recursive!(4, $inner)}.await};(4, $inner:expr) => {async{ async_recursive!(3, $inner)}.await};(3, $inner:expr) => {async{ async_recursive!(2, $inner)}.await};(2, $inner:expr) => {async{ async_recursive!(1, $inner)}.await};(1, $inner:expr) => {async{ async_recursive!(0, $inner)}.await};(0, $inner:expr) => {async{ h19(&String::from("owo"),&0).await; $inner }.await};}asyncfnf(){async_recursive!(14, println!("hello"));}fnmain(){let _ = f();}

r? @eddyb requires a perf run.

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 1146c39 with merge 88f354df8a313170036daa0e4156f8e75242ebd6...

[Mark-Simulacrum]

We'll want to trim it down so that it takes around a second at most on current nightly, but yes adding it definitely seems good to me.

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 88f354df8a313170036daa0e4156f8e75242ebd6 (88f354df8a313170036daa0e4156f8e75242ebd6)

[rust-timer]

Queued 88f354df8a313170036daa0e4156f8e75242ebd6 with parent 8e9d5db, future comparison URL.

[rust-timer]

Finished benchmarking try commit (88f354df8a313170036daa0e4156f8e75242ebd6): 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

[lcnr]

looks mostly neutral, I guess this is ready for review

[eddyb]

r? @nikomatsakis

[tmandry]

Other than perf (which looks neutral to positive for existing cases), the only possible side effects I see here are

• Lower recursion levels
• Fewer duplicate obligations recorded

Which all seem like a good thing!

+1 to adding a case to rustc-perf. I don't think we have to wait on that to merge this, though.

@bors r+

[bors]

📌 Commit 1146c39 has been approved by tmandry

[bors]

⌛ Testing commit 1146c39 with merge 6d3acf5...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: tmandry
Pushing 6d3acf5 to master...

[Mark-Simulacrum]

Along the lines of #72412 (comment), I am nominating this for beta backport. Would someone on the compiler team be willing to approve this? See rationale laid out in that comment.

[Mark-Simulacrum]

@rust-lang/compiler -- cc on the previous comment, this needs to be beta-approved to go out in the release next week. See rationale in #72412 (comment).

[nikomatsakis]

(lgtm)

[nikomatsakis]

is this just for outlining?

[lcnr]

this is mostly so we don't accidentally return here. I kind of like this pattern myself but I do think that it can be somewhat counterintuitive

[RalfJung]

When using a counterintuitive pattern, please add a comment explaining it. :)