-
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
Panic when typing the names on a tuple: index out of bounds: the len is 0 but the index is 0
#16746
Comments
seems relate to thread 'Worker' panicked at /github/home/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ra-ap-rustc_pattern_analysis-0.40.0/src/usefulness.rs:954:18:
index out of bounds: the len is 0 but the index is 0
stack backtrace:
0: rust_begin_unwind
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
1: core::panicking::panic_fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
2: core::panicking::panic_bounds_check
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:208:5
3: ra_ap_rustc_pattern_analysis::usefulness::PlaceInfo<Cx>::split_column_ctors
4: ra_ap_rustc_pattern_analysis::usefulness::compute_exhaustiveness_and_usefulness
5: ra_ap_rustc_pattern_analysis::usefulness::compute_exhaustiveness_and_usefulness
6: ra_ap_rustc_pattern_analysis::usefulness::compute_exhaustiveness_and_usefulness
7: ra_ap_rustc_pattern_analysis::usefulness::compute_match_usefulness
8: hir_ty::diagnostics::expr::BodyValidationDiagnostic::collect |
😭 I'll have a look tomorrow. Fwiw: it would be really nice if the typechecker could be trusted to skip match checking when there's a type error, cause that's always the source of the pattern_analysis panics |
… r=compiler-errors pattern analysis: abort on arity mismatch This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](rust-lang/rust-analyzer#16746)). r? `@compiler-errors`
… r=compiler-errors pattern analysis: abort on arity mismatch This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](rust-lang/rust-analyzer#16746)). r? ``@compiler-errors``
… r=compiler-errors pattern analysis: abort on arity mismatch This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](rust-lang/rust-analyzer#16746)). r? ```@compiler-errors```
We want as much as possible to work if there are errors in unrelated parts of the function though 😅 Of course if the actual match has type mismatches there's not much point in trying to do further checking. |
It should probably suffice to skip it if the scrutinee contains an |
Rollup merge of rust-lang#121987 - Nadrieril:abort-on-arity-mismatch, r=compiler-errors pattern analysis: abort on arity mismatch This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](rust-lang/rust-analyzer#16746)). r? ```@compiler-errors```
I was assuming both of these things were already what we're doing, but I haven't actually checked |
Only for error types, not for types that contain errors
And exhaustiveness checking for |
Oh, that explains things :D |
Sorry for poking my nose into discussion, though I'm getting quite similar error on a medium-sized project. Is there some way to determine what piece of source causes error? In case anyone's interested, I'm getting following error trace:
|
There's no easy way to know which code triggered it unfortunately I think. This has now been fixed on the rustc side, the fix will come to rust-analyzer next update i.e. within a week. @Veykril if you know how to enforce the type check, please do, I haven't looked at the type-checking side of r-a at all |
should be a simple - if scrut_ty.is_unknown() {
+ if scrut_ty.contains_unknown() { for
And adding the same check for the let checking
|
Fixed in #16778. |
I forgot to add a regression test. Do you know where I can add on? I haven't figured out r-a's testing situation yet |
https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-diagnostics/src/handlers/missing_match_arms.rs is where we test match checking (let exhaustiveness checking has its own diagnostic file) |
…r=Veykril minor: Skip match diagnostics for partially unknown types CC #16746 (comment)
When deleting characters from the name of one element in a tuple, if you delete the last one a panic will occur.
To reproduce, create a new empty project and add this to your
main.rs
:Then place your cursor right after the 'b' character and press backspace, making your code look like this:
This panic message is printed to stderr.
rust-analyzer version: 0.4.1867-standalone (037924c 2024-03-03)
rustc version: rustc 1.78.0-nightly (516b6162a 2024-03-03)
(sidenote: I know this is the third issue about panics from me in the past 5 days, I apologize if I'm getting annoying)
The text was updated successfully, but these errors were encountered: