Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint by WaffleLapkin · Pull Request #148214 · rust-lang/rust

WaffleLapkin · 2025-10-28T15:21:27Z

This is an extension to #147382.

With this PR Result<T, Uninhabited> and ControlFlow<Uninhabited, T> considered as must use iif T must be used.

For such cases the lint will mention that T is wrapped in a Result/ControlFlow with an uninhabited error/break.

The reasoning here is that Result<T, Uninhabited> is equivalent to T in which values can be represented and thus the must-used-ness should also be equivalent.

Fixes #65861

rustbot · 2025-10-28T15:21:32Z

r? @fee1-dead

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

fee1-dead

impl LGTM

View changes since this review

jackh726 · 2025-10-29T15:55:21Z

So, the lang team discussed this in the triage meeting today. Overall sentiment was positive that this is probably something we want to do at some point, but there was one concern: people may rely on this today to ensure that people "observe" the state of the Ok variant, since we don't have a nice way today to mark that as must_use without making a newtype. So, to give a concrete example:

fn foo<E>() -> Result<u32, E>; // people may expect that you will check the value of the `u32`

I suggested that we could actually just get some real word data on this using crater. My thought was, we could do an experiment were we error on any function that (after monomorphization) returns Result<T, !> for any T that is not must_use (and maybe separately for any T that is must_use to get a counter set).

I do expect that this will result in a non-small amount of cases, but I think it might be a small enough set that we could browse through and get a sense of if this type of thing is relied upon.

Would you be interested in doing that experiment @WaffleLapkin? If not, I'm happy to help out and try that myself (or I can help if you do want to be involved).

WaffleLapkin · 2025-10-29T16:20:12Z

@jackh726 I'd be happy to do the experiment. I might reach out for some help though ^^'

jackh726 · 2025-10-29T17:09:18Z

Sounds good! Let me know, happy to help if you run into issues.

jackh726 · 2025-12-02T17:38:13Z

Copying this from #148577 (comment)

So, what's very clear is that this pattern comes in a lot of places. Definitely more than I would have expected coming into this. With this being said, I've gone through and opened a few crater results to see if I could spot any examples of @joshtriplett's concern, which was basically like "People may be relying on that Result<T, E> is always must_use to ensure that T is also must_use". The idea (from what I can try to summarize) was that perhaps there is some state in T that would be need to be observed in order to avoid subtle bugs.

So, going into this, I'm looking for types where the Ok variant seems to encode some "meta-state" that must be observed for correctness. There are obviously way too many examples for me to be exhaustive here. And, I have yet to find a situation that follows the pattern to be worried about.

That being said, given that this comes up so much, I think this decision is likely not as "light" as the lang team originally expected. Though, it's completely backwards- and forwards- compatible to make this change and undo later. Here a couple of examples of code I saw, though far from exhaustive.

`no_std_net`

pub trait ToSocketAddrs {
    type Iter: Iterator<Item = SocketAddr>;
    fn to_socket_addrs(&self) -> Result<Self::Iter, ToSocketAddrError>;
}
pub enum ToSocketAddrError {}

`zino_http`

let session_id = self
    .get_header("x-session-id")
    .or_else(|| self.get_header("session_id"))
    .and_then(|s| s.parse().ok()); // <- this parse relies `<String as FromStr>` which has `Err = Infallible`
ctx.set_session_id(session_id);

`zerocopy`

fn checked_shr(self, rhs: Self) -> Option<Self> { self.checked_shr(rhs.try_into().unwrap_or(u32::MAX)) }
                                                                                                     //^^^^^^^^ returns `Result<u32, Infallible>`

clap things

(this comes up a bunch, so just putting an example error, as I haven't dug into the actual pattern; it's also not super clear to me what the actual lint would be)

error: this type will no longer be must used: Result<std::string::String, Infallible>
  --> src/main.rs:72:9
   |
72 | /         /// A path to a project directory or a `Cargo.toml` file. If this is
73 | |         /// not provided, the current directory will be searched.
74 | |         #[clap(verbatim_doc_comment)]
75 | |         path: Option<String>,

Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to #147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes #65861

jhpratt · 2026-05-09T13:52:47Z

stalled

@bors yield

@bors try dist-x86_64-apple

rust-bors · 2026-05-09T13:52:51Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/25598699843

The next pull request likely to be tested is #156361.

rust-bors · 2026-05-09T13:52:51Z

Unknown argument "dist-x86_64-apple". Did you mean to use @bors jobs=<jobs>|parent=<parent>? Run @bors help to see available commands.

jhpratt · 2026-05-09T13:53:05Z

@bors try jobs=dist-x86_64-apple

Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint try-job: dist-x86_64-apple

rust-bors · 2026-05-09T16:31:26Z

☀️ Try build successful (CI)
Build commit: a975fb6 (a975fb6ac43f7ec2e8f1b0a75ab8006da5c54121, parent: 0490dd938541ad996c5ad1ec6e274012afe3e1d4)

…, r=fee1-dead Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to rust-lang#147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes rust-lang#65861

Rollup of 5 pull requests Successful merges: - #148214 (Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint) - #149362 (Add Command::get_resolved_envs) - #155188 (Add regression test for issue 144329) - #155515 (error on empty `export_name`) - #155817 (validate `#[link_name = "..."]` & `#[link(name = "...")]` parameters)

…, r=fee1-dead Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to rust-lang#147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes rust-lang#65861

…uwer Rollup of 10 pull requests Successful merges: - #148214 (Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint) - #149362 (Add Command::get_resolved_envs) - #155705 (Add `str::word_to_titlecase()` to `alloc`) - #155970 (Add mention of sendfile(2) and splice(2) to fs::copy() documentation.) - #156006 (Update a bunch of bootstrap dependencies to remove windows-target) - #155188 (Add regression test for issue 144329) - #155515 (error on empty `export_name`) - #155817 (validate `#[link_name = "..."]` & `#[link(name = "...")]` parameters) - #156107 (remove turbofish notation + use None / Some instead of Option:: (in match documentation)) - #156133 (mark some panicking methods around Duration as track_caller)

rust-bors · 2026-05-10T02:00:59Z

☀️ Test successful - CI
Approved by: fee1-dead
Duration: 3h 11m 9s
Pushing ce89c89 to main...

github-actions · 2026-05-10T02:03:45Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 82bee96 (parent) -> ce89c89 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard ce89c898570852a1bb441d77570596e50bf362c2 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-msvc-ext3: 1h 21m -> 1h 51m (+37.6%)
dist-x86_64-mingw: 1h 59m -> 2h 35m (+30.0%)
test-various: 1h 30m -> 1h 53m (+25.6%)
dist-x86_64-llvm-mingw: 1h 58m -> 1h 28m (-24.8%)
optional-x86_64-gnu-parallel-frontend: 2h 23m -> 1h 49m (-23.6%)
dist-i686-mingw: 2h 9m -> 2h 38m (+22.7%)
armhf-gnu: 1h 25m -> 1h 7m (-20.6%)
dist-x86_64-msvc-alt: 2h 42m -> 2h 11m (-19.0%)
pr-check-1: 25m -> 29m 13s (+16.9%)
aarch64-apple: 2h 31m -> 2h 49m (+12.0%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-05-10T02:49:59Z

Finished benchmarking commit (ce89c89): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.5%	[3.5%, 3.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-5.0%	[-9.9%, -2.3%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-9.9%, 3.5%]	4

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 497.725s -> 498.161s (0.09%)
Artifact size: 397.13 MiB -> 397.12 MiB (-0.00%)

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.96.1` → `1.97.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>rust-lang/rust (rust)</summary> ### [`v1.97.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1970-2026-07-09) [Compare Source](rust-lang/rust@1.96.1...1.97.0) \========================== <a id="1.97.0-Language"></a> ## Language - [Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint](rust-lang/rust#148214) - [Add allow-by-default `dead_code_pub_in_binary` lint for unused pub items in binary crates](rust-lang/rust#149509) - [Stabilize the `div32`, `lam-bh`, `lamcas`, `ld-seq-sa` and `scq` target features](rust-lang/rust#154510) - [Stabilize `cfg(target_has_atomic_primitive_alignment)`](rust-lang/rust#155006) - [Allow trailing `self` in imports in more cases](rust-lang/rust#155137) <a id="1.97.0-Platform-Support"></a> ## Platform Support - [nvptx64-nvidia-cuda: drop support for old architectures and old ISAs](rust-lang/rust#152443) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html <a id="1.97.0-Stabilized-APIs"></a> ## Stabilized APIs - [`Default for RepeatN`](https://doc.rust-lang.org/stable/std/iter/struct.RepeatN.html#impl-Default-for-RepeatN%3CA%3E) - [`Copy for ffi::FromBytesUntilNulError`](https://doc.rust-lang.org/stable/std/ffi/struct.FromBytesUntilNulError.html#impl-Copy-for-FromBytesUntilNulError) - [`Send for std::fs::File` on UEFI](rust-lang/rust#154003) - [`<{integer}>::isolate_highest_one`](https://doc.rust-lang.org/stable/std/primitive.u32.html#method.isolate_highest_one) - [`<{integer}>::isolate_lowest_one`](https://doc.rust-lang.org/stable/std/primitive.u32.html#method.isolate_lowest_one) - [`<{integer}>::highest_one`](https://doc.rust-lang.org/stable/std/primitive.u32.html#method.highest_one) - [`<{integer}>::lowest_one`](https://doc.rust-lang.org/stable/std/primitive.u32.html#method.lowest_one) - [`<{integer}>::bit_width`](https://doc.rust-lang.org/stable/std/primitive.u32.html#method.bit_width) - [`NonZero<{integer}>::isolate_highest_one`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.isolate_highest_one) - [`NonZero<{integer}>::isolate_lowest_one`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.isolate_lowest_one) - [`NonZero<{integer}>::highest_one`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.highest_one) - [`NonZero<{integer}>::lowest_one`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.lowest_one) - [`NonZero<{integer}>::bit_width`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.bit_width) These previously stable APIs are now stable in const contexts: - [`char::is_control`](https://doc.rust-lang.org/stable/std/primitive.char.html#method.is_control) <a id="1.97.0-Cargo"></a> ## Cargo - [Stabilize `build.warnings` config.](rust-lang/cargo#16796) This controls how lint warnings from local packages are treated. Useful for enforcing a warning-free build in CI, replacing `-Dwarnings`. [docs](https://doc.rust-lang.org/nightly/cargo/reference/config.html#buildwarnings) - [Stabilize `resolver.lockfile-path` config.](rust-lang/cargo#16694) This allows specifying the path to the lockfile to use when resolving dependencies. Useful when working with read-only source directories. [docs](https://doc.rust-lang.org/nightly/cargo/reference/config.html#resolverlockfile-path) - [cargo-clean: Error when `--target-dir` doesn't look like a Cargo target directory.](rust-lang/cargo#16712) This prevents accidental deletion of non-target directories. - [Add `-m` shorthand for `--manifest-path`](rust-lang/cargo#16858) - [Remove `curl` dependency from `crates-io` crate](rust-lang/cargo#16936) <a id="1.97.0-Rustdoc"></a> ## Rustdoc - [Stabilize `--emit` flag](rust-lang/rust#146220) - [Stabilize `--remap-path-prefix`](rust-lang/rust#155307) <a id="1.97.0-Compatibility-Notes"></a> ## Compatibility Notes - [Emit a future-compatibility warning when relying on `f32: From<{float}>` to constrain `{float}`](rust-lang/rust#139087) - [Rust will use the v0 symbol mangling scheme by default.](rust-lang/rust#151994) This may cause some tools (such as debuggers or profilers, especially with old versions) to fail to demangle symbols emitted by Rust. It may also cause the formatting of text in backtraces to change. - [Prevent deref coercions in `pin!`, in order to prevent unsoundness.](rust-lang/rust#153457) The most likely case where this might impact users is: writing `pin!(x)` where `x` has type `&mut T` will now always correctly produce a value of type `Pin<&mut &mut T>`, instead of sometimes allowing a coercion that produces a value of type `Pin<&mut T>`. This coercion was previously incorrectly allowed since Rust 1.88.0. - [Deprecate `std::char` constants and functions](rust-lang/rust#153873) - [Warn on linker output by default](rust-lang/rust#153968) - [Remove hidden `f64` methods which have been deprecated since 1.0](rust-lang/rust#153975) - [report the `varargs_without_pattern` lint in deps](rust-lang/rust#154599) - [Forbid passing generic arguments to module path segments even if the module reexports a generic enum variant](rust-lang/rust#154971) - [Error on invalid macho `link_section` specifier](rust-lang/rust#155065) - The encoding of certain `enum`s [have changed](rust-lang/rust#155473). This is not a breaking change, as it only applies to `enum`s without layout guarantees, but is noted here as we've seen people impacted from having made assumptions about the layout algorithm. - [Error on `#[export_name = "..."]` where the name is empty](rust-lang/rust#155515) - [Syntactically reject tuple index shorthands in struct patterns](rust-lang/rust#155698) - [validate `#[link_name = "..."]` & `#[link(name = "...")]` parameters](rust-lang/rust#155817) - On Windows, after calling `shutdown` on a socket to shut down the write side, attempting to write to the socket will now produce a `BrokenPipe` error rather than `Other`. [Map `WSAESHUTDOWN` to `io::ErrorKind::BrokenPipe`](rust-lang/rust#156063) </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).

rustbot assigned fee1-dead Oct 28, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 28, 2025

rustbot mentioned this pull request Oct 28, 2025

Tracking issue for release notes of #148214: Consider Result<T, Uninhabited> and ControlFlow<Uninhabited, T> to be equivalent to T for must use lint #148215

Closed

fee1-dead approved these changes Oct 28, 2025

View reviewed changes

fee1-dead removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 28, 2025

WaffleLapkin mentioned this pull request Nov 6, 2025

[DO NOT MERGE] crater proposed changes in unused must use lint #148577

Closed

WaffleLapkin added the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Nov 13, 2025

WaffleLapkin force-pushed the never-worn-never-type branch from 17a892b to 69a5724 Compare December 2, 2025 10:14

This comment has been minimized.

Sign in to view

WaffleLapkin removed the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Dec 7, 2025

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request May 9, 2026

Auto merge of #148214 - WaffleLapkin:never-worn-never-type, r=<try>

a975fb6

Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint try-job: dist-x86_64-apple

matthiaskrgr mentioned this pull request May 9, 2026

Rollup of 5 pull requests #156369

Closed

JonathanBrouwer mentioned this pull request May 9, 2026

Rollup of 11 pull requests #156371

Closed

JonathanBrouwer mentioned this pull request May 9, 2026

Rollup of 10 pull requests #156374

Closed

This comment has been minimized.

Sign in to view

rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 10, 2026

rust-bors Bot merged commit ce89c89 into rust-lang:main May 10, 2026
13 checks passed

rustbot added this to the 1.97.0 milestone May 10, 2026

WaffleLapkin deleted the never-worn-never-type branch May 11, 2026 10:25

traviscross added needs-reference-pr This language change needs an approved Reference PR to proceed. missed-reference-pr This language change needed a Reference PR and was merged without it. labels May 19, 2026

BoxyUwU mentioned this pull request Jun 24, 2026

Draft release notes for 1.97.0 #158353

Closed

Uh oh!

Uh oh!

Conversation

WaffleLapkin commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 28, 2025

Uh oh!

fee1-dead left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 commented Oct 29, 2025

Uh oh!

WaffleLapkin commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jackh726 commented Oct 29, 2025

Uh oh!

This comment has been minimized.

jackh726 commented Dec 2, 2025

no_std_net

zino_http

zerocopy

clap things

Uh oh!

This comment has been minimized.

jhpratt commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

jhpratt commented May 9, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 9, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 10, 2026

Uh oh!

Uh oh!

github-actions Bot commented May 10, 2026

Test differences

Job duration changes

Uh oh!

rust-timer commented May 10, 2026

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

WaffleLapkin commented Oct 28, 2025 •

edited

Loading

fee1-dead left a comment •

edited by rustbot

Loading

WaffleLapkin commented Oct 29, 2025 •

edited

Loading

`no_std_net`

`zino_http`

`zerocopy`