[experiment] rustc_mir: remove #![type_length_limit] checks.

[eddyb]

The first time we started doubting the usefulness of this check was in #54540, but it's been showing up more.

I've since learned that the PR which added this (#37789) did fix a real issue (#37311) but IMO it's not the most efficient solution (we could instead e.g. periodically warn that monomorphization collection is still ongoing, and that it could indicate an accidental generic blowup), though we may not have anything better in general.

Nevertheless, I think it's a good idea to try this out, even if it may be too late for certain regressions.

This PR was specifically prompted by @hawkw running into a slowdown which may be caused by the #![type_length_limit] check, but we don't really know much for certain yet (and a try build is the easiest comparison that has some guarantees of fairness, plus we can get the perf run results).

cc @nikomatsakis @pnkfelix @arielb1 @lcnr

[rust-highfive]

r? @petrochenkov

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

[eddyb]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 688ec8c with merge dd5d681da665963dde4cc4561bcfc4d348beb75b...

[bors]

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

[rust-timer]

Queued dd5d681da665963dde4cc4561bcfc4d348beb75b with parent 6af1bdd, future comparison URL.

[rust-timer]

Finished benchmarking try commit (dd5d681da665963dde4cc4561bcfc4d348beb75b): 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]

So 1% at best, and only on incr-unchanged runs. Also, from what I'm hearing, it doesn't help much (even if it does lower compile times a bit) for the usecase that motivated this PR.

Perhaps we could test further on some of the reported regressions?

[petrochenkov]

r? @nikomatsakis

[camelid]

@eddyb It appears there are merge conflicts.

[nikomatsakis]

So chalk uses a type-length limit test but in a different way. Instead of forbidding types completely, it "just" causes trait solving to yield ambiguous results when types are getting too big.

[nikomatsakis]

Closing this as it's a super old experiment