add #[track_caller] to slice split_at_mut fn

[0xPoe]

close #83378

[rust-highfive]

r? @joshtriplett

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

[0xPoe]

It looks like many of other methods may also have this issue, do we need to create a new Issue to track and resolve these issues?

[joshtriplett]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit f770774 with merge 7a3a18a727383d099db87281fa8973c5b0b40da3...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7a3a18a727383d099db87281fa8973c5b0b40da3 (7a3a18a727383d099db87281fa8973c5b0b40da3)

[rust-timer]

Queued 7a3a18a727383d099db87281fa8973c5b0b40da3 with parent 2bd94f4, future comparison URL.

[rust-timer]

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

[Dylan-DPC-zz]

@hi-rustin once #83359 is merged i'm planning on targeting the others as well

[nagisa]

I don't think rust-timer is a good way to evaluate the performance impact of this. This should be ideally accompanied by some microbenchmark results, I feel.

[joshtriplett]

@nagisa It's not perfect, but it helps give an idea of the impact. A similar proposal to add #[track_caller] to various Vec methods caused a serious performance hit; by contrast, this seems roughly performance-neutral.

[joshtriplett]

Hmmm. This seems to have a surprisingly high impact on max-rss in some cases.

[Mark-Simulacrum]

max-rss regularly varies up to 15-20% on benchmarks, though we've not pinpointed why, so I think the variation here is just noise.

[joshtriplett]

Ah, that's unfortunate; I've seen many people evaluating max-rss figures from rust-timer without knowing about that level of variability.

[0xPoe]

@joshtriplett Can we merge this PR?

#83359 (comment) It seems that this max-rss change is acceptable?

[0xPoe]

@bors try @rust-timer queue

[rust-timer]

Insufficient permissions to issue commands to rust-timer.

[bors]

@hi-rustin: 🔑 Insufficient privileges: not in try users

[estebank]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit f770774 with merge b1c1d69922eb21f55a08867e6f68fe78e17d2f2b...

[bors]

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

[rust-timer]

Queued b1c1d69922eb21f55a08867e6f68fe78e17d2f2b with parent 3e1c75c, future comparison URL.

[rust-timer]

Finished benchmarking try commit (b1c1d69922eb21f55a08867e6f68fe78e17d2f2b): comparison url.

Summary: This benchmark run did not return any significant changes.

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.

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

[estebank]