Report to the user when dependencies have diagnostics from cargo check/flycheck

[Veykril]

Currently when dependencies don't compile when running cargo check, we will silently eat the error and not display anything, as further checks in the current workspace won't be reached due to cargo check early exiting. We should notify the user this happened in the status bar item.

[wes-adams]

i'd like to take a stab at this one

[RS2007]

Hello, I was trying to replicate this issue. From what I have seen from debugging the main loop, it seems that a compile error in a dependency would lead to the creation of a diagnostic.

1. Is the issue restricted to informing the user that cargo check failed i.e, there is a compile error in the status bar?
2. Does subsequent checks imply, later saves/changes in the workspace?
3. In case of the former, It does not seem very clear from the main loop function why the subsequent cargo checks would fail.

[Veykril]

Basically what we want to happen is when cargo check aka flycheck returns a diagnostic error in a non-workspace member crate we want to inform the user by setting the status to warning, so that the user knows there is an error in one of their dependencies, something which usually prevents cargo check from generating further diagnostics in the workspace itself.

1. Is the issue restricted to informing the user that cargo check failed i.e, there is a compile error in the status bar?

The issue is not about cargo check failing, just an error happening in a non-workspace member crate (whose diagnostics we usually hide).

2. Does subsequent checks imply, later saves/changes in the workspace?

I'm not sure I understand what you mean with this.

3. ...

Again its not about cargo check failing. See above

[RS2007]

Hello, I had a question regarding the presentation of the cargo check error in another workspace. I tried reproducing this error with a simple library inside a cargo bin project.

Shown below is the bin crate that imports an add function from the library crate add_numbers_lib

add_numbers_lib has the add function with the obvious error of multiple semicolons.

Currently I am catching the error and showing a dialog (via the show_and_log_error function).

1. How should I go about presenting this error?
2. For some reason when I run cargo check in the binary crate, it shows no error until I save the lib.rs file in the library crate again. Is there any reason for this behaviour?

[Veykril]

1. We shouldn't pop a notification for that, just set the status to warn in https://github.com/rust-lang/rust-analyzer/blob/cccc7ca2c630865239f68af480878824041c7c05/crates/rust-analyzer/src/reload.rs#L99 and tell the user there that a dependency has errors when running cargo check (no need to put the concrete error there as there might be many)

2. No clue why thats happening for you

[l1nxy]

@Veykril Hi, I would like to give this issue a try. Could you please assign it to me? Also, I have some questions about the code base. Here is the link to the specific code section: https://github.com/rust-lang/rust-analyzer/blob/3ab166637046ab254b11b13ff9108d86b6ed5703/crates/rust-analyzer/src/reload.rs#L143-L147 It seems that the last flycheck error is reporting an issue with the user now. Or maybe I am looking at the wrong position in the code base.

[l1nxy]

@rustbot claim.

[Veykril]

That occurs only when running the flycheck process errors out (like failing to spawn the command etc), not when there is an actual diagnostic.