Revert "Rollup merge of #80538 - JulianKnodt:err_usize, r=lcnr"

[JohnTitor]

This reverts commit be2a3f8, reversing
changes made to 4c4e8e7.

It's second attempt to find the cause of the perf regression in rollup (#80708).

r? @ghost

[JohnTitor]

Hey @rylev sorry for the trouble caused by my rollup! Could you run a perf check for this?

[rylev]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

[bors]

⌛ Trying commit 9ac4831 with merge 492b373476f18fc763cfb5b95ffc8b053d50edb0...

[bors]

☀️ Try build successful - checks-actions
Build commit: 492b373476f18fc763cfb5b95ffc8b053d50edb0 (492b373476f18fc763cfb5b95ffc8b053d50edb0)

[rust-timer]

Queued 492b373476f18fc763cfb5b95ffc8b053d50edb0 with parent c8915ee, future comparison URL.

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

[rust-timer]

Finished benchmarking try commit (492b373476f18fc763cfb5b95ffc8b053d50edb0): 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
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[JohnTitor]

The result is:

So we could say this is the cause.

[rylev]

The performance regressions aren't serious enough to actually warrant reverting. I think they should be investigated, but I'm closing this PR so no one actually merges it.