unused_must_use: Don't warn on Result<(), 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.

[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.