Add slice::remainder

[JulianKnodt]

This adds a remainder function to the Slice iterator, so that a caller can access unused
elements if iteration stops.

Addresses #91733

[rust-highfive]

r? @kennytm

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

[camelid]

triage: What's the status of this PR?

[JohnCSimon]

triage:
@kennytm this is still waiting on review fyi

[Dylan-DPC]

r? @yaahc

[yaahc]

@rustbot author

[yaahc]

Awesome, looks great. Thank you @JulianKnodt ^_^

@bors r+

[bors]

📌 Commit 494901c has been approved by yaahc

[bors]

⌛ Testing commit 494901c with merge d5ae66c...

[klensy]

Is there actually any reason to return empty slice if there is no elements left? Because in that case in next step we need to check is that slice empty on not.

Why not instead:

    pub fn as_slice(&self) -> Option<&'a [T]> {
        if self.finished { None } else { Some(&self.v) }
    }

P.S. currently function named as as_slice but PR's title and descriptions says about remainder.

[JulianKnodt]

@klensy
From a purely performance perspective, it doesn't make sense to wrap an extra layer of Option around a slice since None here conveys the same thing as empty slice, the only possibility of difference would be if the iterator will return None but not been advanced, or if it has completed and returned None already.

If you convert it to None, you'd still have to check the tag of the enum, so there's no perf gain.

From a reader's point of view, I'm not sure it's semantically more clear to return an optional slice. From seeing it, I'd be surprised that it returned an optional slice, and not be sure when it would return None.

[bors]

☀️ Test successful - checks-actions
Approved by: yaahc
Pushing d5ae66c to master...

[rust-timer]

Finished benchmarking commit (d5ae66c): comparison url.

Summary:

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 😿 relevant regressions found

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	0	2	0	0	0
mean2	N/A	1.2%	N/A	N/A	N/A
max	N/A	1.2%	N/A	N/A	N/A

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

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[pnkfelix]

Visiting for weekly performance triage.

The perf run says this regressed externs (a secondary benchmark) incr-full in debug and opt profiles by 1.2%

From my reading of a local cachegrind run on the benchmark, the entirety of the regression is from a closure within rustc_metadata::rmeta::decoder::cstore_impl::provide.

I suspect that may be consistent with overhead you get from slight changes in where definitions end up in the encoded metadata from a change like this to libstd.

But also, if you look at the graph, it looks like this is variance that immediately resolved itself in the history of that benchmark:

@rustbot label: +perf-regression-triaged