-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Match check usefulness index out of bounds #15808
Comments
I guess the problem happens there: rust-analyzer/crates/hir-ty/src/diagnostics/match_check/usefulness.rs Lines 431 to 441 in 46c395d
and probably is_covered_by at least should return false for that case |
Do you happen to have an example code snippet that triggers this? |
The error says that a pattern's type is not the same as it should be in a matched type. Such type mismatches should had the whole match check ruled out earlier but on this case it somehow left undetected. Also the error hints that the affecting @l4l Reproducible example would greatly help here.
|
Note a similar panic being reported here #15883 |
pattern_analysis: Gracefully abort on type incompatibility This leaves the option for a consumer of the crate to return `Err` instead of panicking on type error. rust-analyzer could use that (e.g. rust-lang/rust-analyzer#15808). Since the only use of `TypeCx::bug` is in `Constructor::is_covered_by`, it is tempting to return `false` instead of `Err()`, but that would cause "non-exhaustive match" false positives. r? `@compiler-errors`
…-errors pattern_analysis: Gracefully abort on type incompatibility This leaves the option for a consumer of the crate to return `Err` instead of panicking on type error. rust-analyzer could use that (e.g. rust-lang/rust-analyzer#15808). Since the only use of `TypeCx::bug` is in `Constructor::is_covered_by`, it is tempting to return `false` instead of `Err()`, but that would cause "non-exhaustive match" false positives. r? `@compiler-errors`
pattern_analysis: Gracefully abort on type incompatibility This leaves the option for a consumer of the crate to return `Err` instead of panicking on type error. rust-analyzer could use that (e.g. rust-lang/rust-analyzer#15808). Since the only use of `TypeCx::bug` is in `Constructor::is_covered_by`, it is tempting to return `false` instead of `Err()`, but that would cause "non-exhaustive match" false positives. r? `@compiler-errors`
pattern_analysis: Gracefully abort on type incompatibility This leaves the option for a consumer of the crate to return `Err` instead of panicking on type error. rust-analyzer could use that (e.g. rust-lang#15808). Since the only use of `TypeCx::bug` is in `Constructor::is_covered_by`, it is tempting to return `false` instead of `Err()`, but that would cause "non-exhaustive match" false positives. r? `@compiler-errors`
pattern_analysis: Gracefully abort on type incompatibility This leaves the option for a consumer of the crate to return `Err` instead of panicking on type error. rust-analyzer could use that (e.g. rust-lang#15808). Since the only use of `TypeCx::bug` is in `Constructor::is_covered_by`, it is tempting to return `false` instead of `Err()`, but that would cause "non-exhaustive match" false positives. r? `@compiler-errors`
Closing as non-reproducible |
rust-analyzer version: rust-analyzer 1 (862a300 2023-09-24)
rustc version: 1.72.1 (d5c2e9c34 2023-09-13)
relevant settings: nothing special
editor: helix 23.05
At the editing encountered panic at hir diagnostic:
preceded with the following message:
The code doesn't compiles, though syntax check passes. Unfortunately I'm unable to share the code, nor figure out where MRE. The multi-line stacktrace is shrunk by the editor logger, so I'm only able get
stack backtrace:\n
😮💨The text was updated successfully, but these errors were encountered: