Skip to content

Don't trigger unwrap_used or expect_used on uninhabited Err#16712

Open
samueltardieu wants to merge 1 commit intorust-lang:masterfrom
samueltardieu:features/uninhabited-types-unwrap-expect
Open

Don't trigger unwrap_used or expect_used on uninhabited Err#16712
samueltardieu wants to merge 1 commit intorust-lang:masterfrom
samueltardieu:features/uninhabited-types-unwrap-expect

Conversation

@samueltardieu
Copy link
Copy Markdown
Member

When the Err variant is a known uninhabited type, there is no point in complaining when .unwrap() or .expect(…) are used, as they cannot fail.

One alternative would be to complain and suggest using let Ok(_) = _; which wouldn't fail either, but it may not integrate well into the code flow.

changelog: [unwrap_used] [expect_used]: do not warn on Result types whose Err variant is visibly uninhabited.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 13, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Mar 13, 2026

r? @Jarcho

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

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: 7 candidates
  • 7 candidates expanded to 7 candidates
  • Random selection from Jarcho, dswij, llogiq

When the `Err` variant is a known uninhabited type, there is no point in
complaining when `.unwrap()` or `.expect(…)` are used, as they cannot
fail.

One alternative would be to complain and suggest using `let Ok(_) = _;` which
wouldn't fail either, but it may not integrate well into the code flow.
@samueltardieu samueltardieu force-pushed the features/uninhabited-types-unwrap-expect branch from 1399c84 to f40aac9 Compare March 22, 2026 16:27
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Mar 22, 2026

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Comment on lines +99 to +111
#[derive(Clone, Debug)]
struct S {
x: std::convert::Infallible,
y: u32,
}

fn f(s: Result<String, S>) {
// Check that the compiler sees the `S` type as uninhabited (because of its `x` field)
let Ok(_) = s.clone();
// Do not lint: `s` is necessarily `Ok` as shown above
_ = s.clone().unwrap();
_ = s.clone().expect("uninhabited struct is inhabited");
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A test with an invisibly uninhabited type should also be included.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Mar 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants