diff options
| author | bors <bors@rust-lang.org> | 2024-02-19 11:51:06 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-02-19 11:51:06 +0000 |
| commit | ff8fe522e899b00f363adb46bc81c9ef75af9b7e (patch) | |
| tree | c73085db326537b92ae0acdd12145dafc14df21a /tests/debuginfo/enum-thinlto.rs | |
| parent | d8c8ccc38005c0583d0188a112f88233b151eff0 (diff) | |
| parent | 5390e4ce9bdb822ea4899e2df4383a7076d820cf (diff) | |
| download | rust-ff8fe522e899b00f363adb46bc81c9ef75af9b7e.tar.gz rust-ff8fe522e899b00f363adb46bc81c9ef75af9b7e.zip | |
Auto merge of #16303 - rosefromthedead:non-exhaustive-let, r=Veykril
feat: add non-exhaustive-let diagnostic I want this to have a quickfix to add an else branch but I couldn't figure out how to do that, so here's the diagnostic on its own. It pretends a `let` is a match with one arm, and asks the match checking whether that match would be exhaustive. Previously the pattern was checked based on its own type, but that was causing a panic in `match_check` (while processing e.g. `crates/hir/src/lib.rs`) so I changed it to use the initialiser's type instead, to align with the checking of actual match expressions. I think the panic can still happen, but I hear that `match_check` is going to be updated to a new version from rustc, so I'm posting this now in the hopes that the panic will magically go away when that happens.
Diffstat (limited to 'tests/debuginfo/enum-thinlto.rs')
0 files changed, 0 insertions, 0 deletions
