Using <Iter>::new instead of exposing internal fields

[tesuji]

As requested in #76311 (comment)

[lcnr]

Thanks, LGTM. It might be better to create the NonNull outside of the new functions so that these functions don't have any additional safety requirements.

[lcnr]

slice.iter is quite hot, let's see if we somehow regress something here.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 75ea5bcb25469d100c5063fa3cf08ede866a2d32 with merge 949e85c6bc2e139a5e9b07b26df01c81c9ecd99e...

[bors]

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

[rust-timer]

Queued 949e85c6bc2e139a5e9b07b26df01c81c9ecd99e with parent 95386b6, future comparison URL.

[rust-timer]

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

You might have to put #[inline] on at least some of these functions.

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit eafe1b365e6784208d7df8462d22da5c2b207f37 with merge d2df5ef8b0f37065ba646a8a28bb6085e0d3b724...

[bors]

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

[rust-timer]

Queued d2df5ef8b0f37065ba646a8a28bb6085e0d3b724 with parent 95386b6, future comparison URL.

[rust-timer]

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

LGTM

perf also seems fine now 👍

[lcnr]

Thanks 👍

@bors r+ rollup=never

[bors]

📌 Commit 39732ab8f6e6493079d5e9364521e44d133049fa has been approved by lcnr

[tesuji]

Did you mark all the file as viewed ? Because I intend to squash some commits together.

[lcnr]

now I did 😆 go ahead

[tesuji]

Done.

[lcnr]

@bors r+ rollup=never

[bors]

📌 Commit b659370 has been approved by lcnr

[bors]

⌛ Testing commit b659370 with merge c6ab8e5...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: lcnr
Pushing c6ab8e5 to master...