Warn must_use in tuple #29815
Warn must_use in tuple #29815
Conversation
|
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
|
Ping. |
|
☔ The latest upstream changes (presumably #30043) made this pull request unmergeable. Please resolve the merge conflicts. |
sanxiyn
force-pushed
the
tuple-must-use
branch
from
f08ccec
to
b31cffe
Compare
|
Another ping. |
|
I am not sure this is a bug. |
|
r? @nrc |
| @@ -45,4 +45,7 @@ fn main() { | |||
| let _ = foo::<isize>(); | |||
| let _ = foo::<MustUse>(); | |||
| let _ = foo::<MustUseMsg>(); | |||
|
|
|||
| foo::<(MustUse, ())>(); //~ ERROR: unused result which must be used | |||
| foo::<(MustUseMsg, ())>(); //~ ERROR: unused result which must be used: some message | |||
There was a problem hiding this comment.
Can you add checks that when we do use the result, then it is not an error?
|
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 |
|
cc @nagisa who reported the original issue. |
|
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. |
|
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 |
| if result.is_some() { | ||
| return result; | ||
| } | ||
| } |
There was a problem hiding this comment.
Alternatively, something like this might work:
tys.iter()
.filter_map(|ty| check_must_use(cx, ty))
.next()
|
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 |
cc #26291.