Warn must_use in tuple

[sanxiyn]

cc #26291.

[rust-highfive]

r? @arielb1

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

[sanxiyn]

Ping.

[bors]

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

[sanxiyn]

Another ping.

[arielb1]

I am not sure this is a bug.

[arielb1]

r? @nrc

[nrc]

Can you add checks that when we do use the result, then it is not an error?

[nrc]

The code looks fine (other than the minor things mentioned). But this would be a breaking change, so I would like to check with other memebers of the tools team that this should land.

Whilst it seems like a good idea, the must use lint is a little bit questionable in this case - if a field on a struct was must_use, we wouldn't assume the whole struct is must_use, so it is not clear if a tuple should be either.

cc @rust-lang/tools

[sanxiyn]

cc @nagisa who reported the original issue.

[sanxiyn]

Does strengthening a lint count as a breaking change? I thought it specifically didn't count as one. I'd like a clarification since I have another PR(#30021) that strengthens a lint.

[steveklabnik]

https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md#lints

[nagisa]

Since it is a warning, I wouldn’t count it a breaking change in any imaginable way. There was a lengthy discussion about users of #[deny(...)] in context of new warnings and we basically decided to just ignore they exist AFAIR.

[frewsxcv]

Alternatively, something like this might work:

tys.iter()
   .filter_map(|ty| check_must_use(cx, ty))
   .next()

[alexcrichton]

We discussed this during the tools triage meeting today (sorry for the delay!) and the conclusion was that we don't want to merge this at this time. This arguably isn't idiomatic to return a tuple of results (vs a result of tuples) and it also doesn't extend well to other type compositions like enums/structs (you can ignore a struct which contains a #[must_use]. Thanks for the PR though!