Warn using last and count to exhaust an iterator

[Kestrer]

This adds the same #[must_use] attribute as used in collect to count and last, as it also does not make sense to not use the result there.

[rust-highfive]

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

[m-ou-se]

There's some discussion in #48926 about when to use #[must_use] in the standard library. The functions changed in this PR (count and last) don't seem to fall into the category of functions where ignoring the result definitely indicates a bug (like s.to_uppercase();) or there is a more efficient/better version if you don't need the result (like mem::replace). For now, applying #[must_use] is done conservatively in the standard library, until the discussion on #48926 comes to a conclusion.

Marking this as blocked on #48926.

[Kestrer]

Wouldn't count/last be less efficient, as the operation performed needs to store state, or is it so trivial that we can rely on the compiler to optimize it out?

[m-ou-se]

Wouldn't count/last be less efficient, as the operation performed needs to store state, or is it so trivial that we can rely on the compiler to optimize it out?

My guess is that yes, it'd get optimized out. The #[must_use] for mem::replace is not just there because of the resulting efficiency, but also because *a = 1 is less verbose and conceptually much simpler than mem::replace(a, 1). One could argue that .for_each(drop) is conceptually simpler than .count(), but the difference is much smaller. So I'll leave this discussion to the linked issue for now. Feel free to add your thoughts about #[must_use] to that issue. I'm not rejecting your PR (I personally think it'd be a good addition!), but it'd be better to discuss it in the bigger context of #[must_use] in std. (See also #52201 and #50462.)

By the way: the CI is failing because the expected test output still needs to be updated. You can do that by running ./x.py tests src/test/ui --bless (and --stage=1 --keep-stage=0 is probably useful to make it fast).

[Kestrer]

Should I close this or leave it open as blocked?

[jyn514]

It might make sense to make this a clippy lint instead.

[scottmcm]

I have a fuzzy memory that @withoutboats may have had thoughts on one of these specifically...

[bors]

☔ The latest upstream changes (presumably #76391) made this pull request unmergeable. Please resolve the merge conflicts.

[shepmaster]

r? @m-ou-se

[dtolnay]

@rustbot label -S-blocked +S-waiting-on-team

Marking waiting-on-team because the discussion in #48926 appears to have reached a stopping point a while ago.

[m-ou-se]

This was briefly discussed in the libs api meeting recently. See rust-lang/libs-team#35 for the guideline we're using now for #[must_use]. The additions in this PR fall outside of the criteria listed there, so I'm closing this.

Feel free to continue the discussion on #48926.