Change:
<ins> error[E0317]: `if` may be missing an `else` clause --> $DIR/irrefutable-if-let-without-else.rs:8:5 | LL |   fn foo(x: Enum) -> i32 { |                      --- expected `i32` because of this return type LL | /     if let Enum::Variant(value) = x { LL | |         value LL | |     } | |_____^ expected `i32`, found `()` | = note: `if` expressions without `else` evaluate to `()` = help: consider adding an `else` block that evaluates to the expected type help: consider using an irrefutable `let` binding instead | LL ~     let Enum::Variant(value) = x; LL ~         value | error[E0317]: `if` may be missing an `else` clause --> $DIR/irrefutable-if-let-without-else.rs:13:5 | LL |   fn bar(x: Enum) -> i32 { |                      --- expected `i32` because of this return type LL | /     if let Enum::Variant(value) = x { LL | |         let x = value + 1; LL | |         x LL | |     } | |_____^ expected `i32`, found `()` | = note: `if` expressions without `else` evaluate to `()` = help: consider adding an `else` block that evaluates to the expected type help: consider using an irrefutable `let` binding instead | LL ~     let Enum::Variant(value) = x; LL ~         let x = value + 1; LL ~         x | error[E0317]: `if` may be missing an `else` clause --> $DIR/irrefutable-if-let-without-else.rs:19:5 | LL |   fn baz(x: Struct) -> i32 { |                        --- expected `i32` because of this return type LL | /     if let Struct(value) = x { LL | |         let x = value + 1; LL | |         x LL | |     } | |_____^ expected `i32`, found `()` | = note: `if` expressions without `else` evaluate to `()` = help: consider adding an `else` block that evaluates to the expected type help: consider using an irrefutable `let` binding instead | LL ~     let Struct(value) = x; LL ~         let x = value + 1; LL ~         x | error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0317`. </ins>

Discussion:
The following code () gives the following error: which is weird, since the clause would never be visited even if it was present. The equivalent one-arm match compiles just fine (expectedly). Adding an branch to the is, of course, possible, but unelegant, and really shouldn't be needed, as it can be inferred at compile time.
You can match irrefutably without in this case: though maybe we should give this special diagnostics.
I think this is too niche to deserve a special diagnostics (and I don't think we should substantially work on diagnostics for until let_chains is implemented). is defined by a desugaring: becomes: so what you really wrote is: The block is typed at which does not unify with unless it is also typed at .
I didn't know was a valid syntax. If I did, I probably wouldn't have filed the issue, because of course, in hindsight, that's how you write an infallible . (With that knowledge in mind) I agree that it's only a diagnostics issue and no language change is needed here. And I fully agree that it's a niche low-priority quirk that should maybe be fixed "someday". (I don't know what but even then I'd guess that this one is lower priority than that).
I think the appropriate thing to do here would be to lint on , which would have clarified things.
We already do.
But we do only after typechecking, and we don't if there are any errors before then. Quite a few lints have similar issues related to not happening early enough.
How do you know that the pattern is irrefutable before match checking in HAIR?
You can't, but you can write the lint in such a way that it triggers regardless. We're getting to typechecking, we should be able to detect irrefutability by then. It just can't use the standard linting machinery (like a few other lints already do to avoid being silenced by accident).