Added ExactSizeIterator bound to return types

[hashedone]

Fixes #66865

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[petrochenkov]

@oli-obk
What is the goal here?
Since this is a compiler and everything is unstable, we can always add these bounds when necessary (the .len() method is actually used), and avoid the noise until they are not necessary.

AFAIR, this shouldn't affect performance as well, specialization (if it's used for ExactSizeIterator at all) considers the underlying type of impl Trait and not bounds.

[petrochenkov]

Let's check the perf anyway.
@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit d97379a with merge af6ea8f767c5b62341b6a274297a57641a2ae0ad...

[oli-obk]

In miri we had to do some funky workaround with testing whether the iterator still has elements and whether it was finished instead of just asserting the len and then zipping two iterators.

[bors]

☀️ Try build successful - checks-azure
Build commit: af6ea8f767c5b62341b6a274297a57641a2ae0ad (af6ea8f767c5b62341b6a274297a57641a2ae0ad)

[rust-timer]

Queued af6ea8f767c5b62341b6a274297a57641a2ae0ad with parent 5c5c8eb, future comparison URL.

[petrochenkov]

@oli-obk

In miri we had to do some funky workaround with testing whether the iterator still has elements and whether it was finished instead of just asserting the len and then zipping two iterators.

Can the bound be added only to that specific iterator then?
(Miri and rustc are developed synchronously and need to collaborate on things like this anyway.)

[oli-obk]

Sure, if that is preferrable, let's limit it to the mir::Body functions

[hashedone]

I will correct this todays evening, but I am wondering - if the case is to change some return types clearly for miri usage, maybe it would be better to use this change in the same commit - I mean add a correction to miri. I know about one place where the "hack" is done, I am not sure if there are other places - @oli-obk is there much code to check for similar cases? I am not familiar with miri, but I would bo more than happy to dive into it.

[oli-obk]

No I believe right now it's just the one case in miri. I suggest to land the rustc change independently, as otherwise you need to synchronize up the submodule, which can be quite messy. After the change has been merged in rustc, you can do the change to miri without having to worry about submodules.

[hashedone]

Sure, I will go this way.

[rust-timer]

Finished benchmarking try commit af6ea8f767c5b62341b6a274297a57641a2ae0ad, comparison URL.

[petrochenkov]

@bors r+

[bors]

📌 Commit 989bf84 has been approved by petrochenkov