Implement missing TrustedLen for core and alloc types

[fereidani]

While working on #160813 I noticed TrustedLen is missing for the LinkedList, I suspected that other modules are missing the implementation too, so I wrote a small script to scan the project and found these candidates which implement ExactSizeIterator but not the TrustedLen, Reviewed the code just to make sure they are actually meet TrustedLen requirement and then I've added missing implementations.

While editting I found out there are instances of FusedIterator missing too, So I've added them too.

I think most important missing one is the impl<I: TrustedLen + ?Sized, A: Allocator> TrustedLen for Box<I, A> which inherits TrustedLen for a Box to a TrustedLen implementer.

I did this only for core and alloc, I ignored script reports for the std but I think it worth looking into, specially for the HashMap:

FusedIterator::missing CommandArgs in library/std/src/process.rs
TrustedLen::missing CommandArgs in library/std/src/process.rs
FusedIterator::missing CommandEnvs in library/std/src/process.rs
TrustedLen::missing CommandEnvs in library/std/src/process.rs
FusedIterator::missing Args in library/std/src/env.rs
TrustedLen::missing Args in library/std/src/env.rs
FusedIterator::missing ArgsOs in library/std/src/env.rs
TrustedLen::missing ArgsOs in library/std/src/env.rs
TrustedLen::missing Iter in library/std/src/collections/hash/set.rs
TrustedLen::missing IntoIter in library/std/src/collections/hash/set.rs
TrustedLen::missing Drain in library/std/src/collections/hash/set.rs
TrustedLen::missing Iter in library/std/src/collections/hash/map.rs
TrustedLen::missing IterMut in library/std/src/collections/hash/map.rs
TrustedLen::missing IntoIter in library/std/src/collections/hash/map.rs
TrustedLen::missing Keys in library/std/src/collections/hash/map.rs
TrustedLen::missing Values in library/std/src/collections/hash/map.rs
TrustedLen::missing ValuesMut in library/std/src/collections/hash/map.rs
TrustedLen::missing IntoKeys in library/std/src/collections/hash/map.rs
TrustedLen::missing IntoValues in library/std/src/collections/hash/map.rs
TrustedLen::missing Drain in library/std/src/collections/hash/map.rs
FusedIterator::missing CommandArgs in library/std/src/sys/process/unsupported.rs
TrustedLen::missing CommandArgs in library/std/src/sys/process/unsupported.rs
FusedIterator::missing CommandArgs in library/std/src/sys/process/windows.rs
TrustedLen::missing CommandArgs in library/std/src/sys/process/windows.rs
FusedIterator::missing CommandArgs in library/std/src/sys/process/uefi.rs
TrustedLen::missing CommandArgs in library/std/src/sys/process/uefi.rs
FusedIterator::missing CommandArgs in library/std/src/sys/process/motor.rs
TrustedLen::missing CommandArgs in library/std/src/sys/process/motor.rs
FusedIterator::missing CommandEnvs in library/std/src/sys/process/env.rs
TrustedLen::missing CommandEnvs in library/std/src/sys/process/env.rs
FusedIterator::missing CommandArgs in library/std/src/sys/process/unix/common.rs
TrustedLen::missing CommandArgs in library/std/src/sys/process/unix/common.rs
FusedIterator::missing CStringIter in library/std/src/sys/process/unix/common/cstring_array.rs
TrustedLen::missing CStringIter in library/std/src/sys/process/unix/common/cstring_array.rs
FusedIterator::missing Args in library/std/src/sys/args/common.rs
TrustedLen::missing Args in library/std/src/sys/args/common.rs
FusedIterator::missing Args in library/std/src/sys/args/unsupported.rs
TrustedLen::missing Args in library/std/src/sys/args/unsupported.rs
FusedIterator::missing Args in library/std/src/sys/args/sgx.rs
TrustedLen::missing Args in library/std/src/sys/args/sgx.rs
FusedIterator::missing Args in library/std/src/sys/args/zkvm.rs
TrustedLen::missing Args in library/std/src/sys/args/zkvm.rs

This is related to #37572

• I did not use an LLM to create a change in this PR.
• I used an LLM to create a change in this PR, and I have explained below how it was used.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 9a3fc0e (9a3fc0e26f41ccaf3ebb3a1bcfa6e28817886e86)
Base parent: 8a2fbe3 (8a2fbe3ea881ec68b9f06510fd1a1484cdf5bb6b)

[rust-timer]

Finished benchmarking commit (9a3fc0e): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

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

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (secondary -1.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-6.9%, -0.4%]	27
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.7%	[0.5%, 1.2%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.8%	[-1.3%, -0.4%]	9
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 454.914s -> 461.019s (1.34%)
Artifact size: 398.40 MiB -> 398.35 MiB (-0.01%)

[Mark-Simulacrum]

I think the TrustedLen impls are not observable on stable (outside of better performance in some cases), so while we'll need some review to ensure correctness, those seem fine. However, implementing FusedIterator is a stable guarantee, so we'll definitely need to get libs FCP on that - I'd split that out into a separate PR. I think the format that would make the most sense for approving it is something like this:

• impl FusedIterator for std::process::CommandArgs

with any relevant conditions on the generics included. That should focus on the public API rather than any internal changes needed to facilitate that. That can then be FCPd.

Note that for those structures that delegate their iterator implementation, I think we should make sure that we have a static assertion that the inner iterator type is also a FusedIterator. Any platforms where we can't consistently provide FusedIterator (I'd hope none, but let's check) should be separated out into a separate PR.

I wrote a small script to scan the project and found these candidates which implement ExactSizeIterator but not the TrustedLen, Reviewed the code just to make sure they are actually meet TrustedLen requirement and then I've added missing implementations.

Is there a Clippy lint for this? I suspect the vast majority of Iterator types want to be Fused, and the vast majority of ExactSize iterators can be TrustedLen. It seems like we ought to catch that earlier if possible, and a Clippy and/or rustc lint for it would make sense to me. (Obviously in the cases that it doesn't make sense we can allow the lint).

[fereidani]

I think the TrustedLen impls are not observable on stable (outside of better performance in some cases), so while we'll need some review to ensure correctness, those seem fine. However, implementing FusedIterator is a stable guarantee, so we'll definitely need to get libs FCP on that - I'd split that out into a separate PR.

Thank you for your guidance, I didn't know that, I removed FusedIterator implementations, once we merged this PR, I'll start sending separate PRs for each missing FusedIterator implementation.

Is there a Clippy lint for this? I suspect the vast majority of Iterator types want to be Fused, and the vast majority of ExactSize iterators can be TrustedLen. It seems like we ought to catch that earlier if possible, and a Clippy and/or rustc lint for it would make sense to me. (Obviously in the cases that it doesn't make sense we can allow the lint).

I checked and didn't find any rule related to this. I wrote a simple naive python script that reads formatted rust.
Could be useful to add a clippy rule for it, but I'm not sure if all ExactSizeIterators are FusedIterator or TrustedLen, there might be edge cases but we can always ignore those rare edge cases.

[fereidani]

@rustbot ready

[Mark-Simulacrum]

Can you update title + description + squash commits?

I'd also like a second look from @the8472 in case I missed anything for the impls here, given they are making new soundness (but not correctness) guarantees, including whether we need FCP -- I think no, because TrustedLen is unstable, but not sure if it's actually exposed somewhere.

[fereidani]

Thank you, I did most of it but I'll wait for the review then I will squash commits to avoid multiple CI runs.