fly check panic

[qjerome]

rust-analyzer version: 0.3.2264

rustc version: rustc 1.81.0 (eeb90cda1 2024-09-04)

editor or extension: VSCode

I am getting this error:

2025-01-16T14:02:42.513421189+01:00 ERROR flycheck task panicked: Any { .. }
thread 'Worker' panicked at crates/rust-analyzer/src/handlers/notification.rs:333:25:
index out of bounds: the len is 1 but the index is 1
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_bounds_check
   3: core::ops::function::FnOnce::call_once{{vtable.shim}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2025-01-16T14:02:45.05267552+01:00 ERROR flycheck task panicked: Any { .. }

I checked the code at https://github.com/rust-lang/rust-analyzer/blob/1f717b0acdccf6969655a8a1ddf6b718dfba6ca6/crates/rust-analyzer/src/handlers/notification.rs#L333C1-L333C82 and it seems the accessed index is not checked against OOB access. As I am not very familiar with the r-a code base I am tempted to fix this just checking that idx is in bounds using get methods instead of [] access but maybe it is the symptom of an issue that needs to be corrected elsewhere in the code.

Cheers,

[Veykril]

There seems to be something else going on, the index there should always be in bounds, though we might be racing when the workspaces switch.

[qjerome]

Let me know if I can help diagnosing the issue

[ChayimFriedman2]

Do you have a reproduction?

[qjerome]

I just have my huge project requiring some setup ... I would need to figure out how to repro the issue on a small repository but I have not the time for this right now !

[qjerome]

I tried to build a minimal repro project for several hours but in vain ... Yet I do still have the error even with the latest version of r-a.
The link to my project, where I have the issue is: https://github.com/kunai-project/kunai

The particularities of that project that may trigger the error above are the following:

• a cargo workspace running on Rust stable toolchain
• a rust-analyzer.linkedProjects running on nightly Rust because it needs a custom target only available in nightly
• several cargo related tasks are actually handled by a custom xtask: such as clippy, build, run ... (see cargo xtask -h for details)

I hope this will help you ...

[qjerome]

Even though I didn't find a way to reproduce the issue I may have found why this happens:

My project is configured with "rust-analyzer.check.invocationStrategy": "once",
Looking at the code creates a flycheck Vec of size 1 :

rust-analyzer/crates/rust-analyzer/src/reload.rs

Line 812 in 1f23156

self.flycheck = match invocation_strategy {

Moreover in the GlobalState::switch_workspaces method it seems there are at least two code path leading to workspaces modification:

rust-analyzer/crates/rust-analyzer/src/reload.rs

Line 497 in 1f23156

self.workspaces = Arc::new(workspaces);

rust-analyzer/crates/rust-analyzer/src/reload.rs

Line 514 in 1f23156

self.workspaces = Arc::new(workspaces);

Maybe I missed something but nowhere I found that the size of workspaces Vec is checked against the size of the flycheck Vec. So it is totally possible that when enumerating workspaces and try to get something in flycheck we get OOB at

rust-analyzer/crates/rust-analyzer/src/handlers/notification.rs

Line 333 in 1f717b0

world.flycheck[idx].restart_for_package(package, target);

Maybe you guys (more familiar with r-a code) know how to reproduce a case where that condition (1 element in flycheck and n>1 elements in workspaces) triggers but I am definitely not able to reproduce it elsewhere than in my big project you probably don't want to clone and look at.

Nevertheless, this issue prevents r-a to perform well (because of the panic) on some part of my code, which is very annoying. This is why I made a low impact working patch: master...qjerome:rust-analyzer:fix-notification-panic

Please let me know if you want me to make a PR or if you plan to find and fix the root cause.