unused_must_use: Don't warn on Result<(), Uninhabited> or ControlFlow<Uninhabited, ()>

[joshtriplett]

This suppresses warnings on things like Result<(), !>, which helps simplify code using the common pattern of having an Error associated type: code will only have to check the error if there is a possibility of error.

This will, for instance, help with future refactorings of write! in the standard library.

As this is a user-visible change to lint behavior, it'll require a lang FCP.

---

My proposal, here, is that we handle this simple case to make common patterns more usable. This does not rule out the possibility of adding more cases in the future, including general trait-based cases. However, I don't think we should make this common case wait on the more general cases. In particular, this solution does not close any doors on replacing this special case with a general case.

This would unblock some planned work in the standard library to make write! more usable for infallible cases (e.g. writing into a Vec or String).

[rustbot]

r? @fmease

rustbot has assigned @fmease.
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

[fmease]

I'll be waiting for the outcome of T-lang's triage meeting before reviewing this since the proposed rules might very well change drastically (e.g., trait-driven vs. not trait-driven; cc Zulip discussion).

[joshtriplett]

Summarizing the Zulip discussion:

• What this PR does: We could do this by looking for any uninhabited type. This takes into account types that are not publicly known to be uninhabited, and types that are marked as #[non_exhaustive] (so they may not always be uninhabited).
• We could do this by hardcoding types like ! or Infallible.
• We could do this by identifying the types in some other way, such as a dedicated attribute, or a trait.
• We could require people to use Result::into_ok() (once stabilized). This would be less readable, though.
• Some discussion about cases like enums with variants that are sometimes configured out.

[joshtriplett]

My proposal, here, is that we handle this simple case to make common patterns more usable. This does not rule out the possibility of adding more cases in the future, including general trait-based cases. However, I don't think we should make this common case wait on the more general cases. In particular, this solution does not close any doors on replacing this special case with a general case.

This would unblock some planned work in the standard library to make write! more usable for infallible cases (e.g. writing into a Vec or String).

[Amanieu]

As a general rule I think this should follow the same rules what let Ok(()) = foo would accept.

[joshtriplett]

I've updated this to follow the same pattern as other inhabitedness checking, of only caring about non_exhaustive from external crates.

I've also updated it to handle ControlFlow.

[niacdoial]

huh...
github doesn't let me choose your branch as a PR destination.
er... anyway, I would like to contribute a test (making sure unresolved type aliases behave like inhabited types), if you'll let me:
https://github.com/niacdoial/rust-contrib-fork/tree/must_use_uninhab

[joshtriplett]

huh... github doesn't let me choose your branch as a PR destination. er... anyway, I would like to contribute a test (making sure unresolved type aliases behave like inhabited types), if you'll let me: https://github.com/niacdoial/rust-contrib-fork/tree/must_use_uninhab

Added, thanks!

[scottmcm]

Is this the same as "don't must_use warn on things that are ZSTs"?

Thus it could be phrased as "change the ()-specific rule to any ZST, not just the unit ZST".

[joshtriplett]

@scottmcm I don't want to generalize that here yet, because someone might e.g. have some #[must_use] ZST that represents "capture this token and pass it to some other function to prove you got an Ok", and I wouldn't want to override that. Some more general design could argue for that, but () is the case that I'm confident any more general solution will encompass.

[traviscross]

This makes sense to me, in particular how this helps with write!, etc., and the test cases seem right.

@rfcbot fcp merge

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[WaffleLapkin]

Is there a reason why this checks for T = ()? Result<T, !> is basically T, so I'd expect this to not check for (). In #147854, which I opened because I haven't seen this PR, I just return is_ty_must_use(cx, args.type_at(0), expr, span) here.

[joshtriplett]

@WaffleLapkin I can see the argument for that, but it'd be less clear-cut. Result<(), !> has only one possible value, so there's zero value in checking it at all, and it seems safe to unconditionally make it ignore must_use. Something like Result<u32, !>, on the other hand, would currently be flagged by the must_use on Result, and it would be a potential surprise to people to stop doing that; people might be expecting to have to capture the return value with let Ok(value) = ..., for instance.

If we were going to potentially suppress warnings on Result<T, !>, I think that'd need a separate FCP. We might also want to let people know that they may want to mark the function #[must_use] if they were previously counting on the Result to do that.

Separately from that, if we're checking for T being #[must_use], it'd be nice to have a design where a function returning Result<T, E> produces an unused_must_use warning if you apply a ? and then ignore the T. But that doesn't have to happen right away, and I'm all for incremental results.

One way or another, though, I think that would be an additional change requiring an additional FCP.

[joshtriplett]

I'm going to go ahead and merge given the FCP and @fmease's r=me, to get the incremental improvement that's already been approved. But we can always evaluate further enhancements to this further in the future.

@bors r=fmease rollup

[bors]

📌 Commit 7aa7ecc has been approved by fmease

It is now in the queue for this repository.