Rust: Integrate with bacon - Proper automatic checks/recompilation for (larger) workspaces

[DragonDev1906]

Check for existing issues

• [X] Completed

Describe the feature

Motivation (and my workflow)

I'm working in a larger workspace, where the defaults for rust-analyzer are near useless (due to it taking so long). The Zed Documentation even acknowledges this, providing a really useful but in my opinion limiting suggestion. I chose to only disable --workspace because I still want cargo check to run when I save a file.

"check": {
  "workspace": false
}

Unfortunately this has the big downside that when I edit crate A zed/rust-analyzer checks crate A, but doesn't check crate B which has A as a dependency, which isn't really useful if A is an internal dependency. To avoid having this problem I run bacon in the background, which watches for file changes and runs cargo check (or clippy) against all crates that are affected by a change. In the example above it checks A and B but no crate that doesn't (directly or indirectly) depend on A.

I believe Zed could become a lot better by integrating (or working together) with this existing tool.

To do that it also runs cargo check once in the beginning for the entire workspace.

Proposed feature

I'd love if Zed could include or at least work with bacon. Either by:

• Including bacon in the editor, starting it when opening a rust project OR
• Processing the .bacon-locations file it outputs when using bacon -e (by itself doesn't contain all the information) OR
• Use the same logic as bacon to decide when a crate should be recompiled.

I'd suggest one of the first two approaches. Note that this can just as well be used for smaller projects for which rust-analyzer works well enough (or enabled/disabled in the settings). The first two are easier to implement and maintain.

The ideal solution (in my opinion)

• Disable cargo check in rust_analyzer, it doesn't work well for large workspaces (disabled by default or via opt-in to bacon in the settings)
• Integrate with bacon, showing all diagnostics it finds.
• Have some way of showing the output of bacon directly (basically just a terminal for it). For larger errors (e.g. caused by lifetimes or generics) I find the output of cargo check (bacon forwards the output of cargo check) a lot more useful than Zeds current "hover over the line" approach, since cargo check and bacon show everything you need in a compact format. I find this really useful and currently use it more often than Zeds diagnostics window (since bacon somehow feels faster). This could (in theory) even be done by parsing the output of cargo check/bacon to show it directly in the diagnostics overview and have it editable, but that'd be the cherry on top.
• Have some way to click on <file>:<line>:<col> links in the output of bacon, and/or those links when outputted to the terminal when running cargo check manually in the terminal. At the moment you have to copy that line into the file finder (my current approach). EDIT (2024-09-02): It is currently possible to control-click on the <file>:<line>:<col> links when running bacon in the built-in terminal (which I found out some time after creating this issue)

Note that I'm still using rust-analyzer, but I find bacon's approach to re-checking and error printing a lot more useful.

Alternative considered

Zed could (as mentioned above) re-implement the decision which crates to recompile, but I think that adds unnecessary complexity/overhead when such a tool already exists, which has additional features like selecting between cargo check, cargo clippy, cargo test, ... (in the newest version even pausing the checking when working on a larger set of errors.

Additional notes

• There exists a similar (unfortunately somewhat stale) issue on vscode: https://github.com/Canop/bacon/issues/158
• The biggest downside I've seen so far is that bacon and rust-analyzer sometimes "fight" over who locks the package cache first.

If applicable, add mockups / screenshots to help present your vision of the feature

Here I'm running bacon in a terminal in Zed, and the output is, even for this simple error, (in my opinion) a lot more readable than the diagnostics from rust-analyzer or rustc. Imagine having this output in the diagnostics view and have it editable. Or at the very least have the link in bacon's output be clickable, going directly to the source file.

[maan2003]

what if we filter diagnostics to only rustc source, the last diagnostic in zed is more readable than terminal IMO

[DragonDev1906]

That would also work, as that's also what bacon's output is based on.

Though personally I'd still use bacon in that case, even if it means one more click to edit it, as my main issue with the built-in diagnostics isn't just the way errors are displayed:

• So far I haven't been able to get rust-analyzer to give me errors in a reasonable time frame without missing half of them, as it either takes forever (--workspace, the default) or doesn't compile the other crates (e.g. change in A but B that depends on it isn't compiled or something like that). I don't know what's different but I haven't had that problem with bacon.
• Bacon allows you to pause at any time, something you cannot do with the built-in diagnositcs as far as I know
• In the newest version of bacon you can even show how many changes (number filesystem events) there are since the error was generated, making it clear when the code has been updated since the errors/warnings where detected.

But the example above is also one of the simplest cases, where everything is in one file. Consider the following:

The diagnostics pane shows the necessary information, but IMO fails in two things:

• The error from rustc (and the output of bacon) can be read from the top to the bottom. It shows the most important things first and proposed fixes are more intuitive by looking like code itself (just with color where things are added/changed). Yes, that's hard/near impossible to achieve when trying to show it in-line.
• When multiple files are involved (which is often the case) the diagnostics pane fails to show a lot of relevant information (all other errors in the screenshot are something unrelated):
  • The client::do_something(client::MyStruct{}) line shows the required by a bound introduced by this call note, but the way more relevant location is where the function is defined, not where it is called.
  • In this case the (really useful) help message of adding #[derive(Debug)] isn't even shown (only in the red error message) because it is in another file.

The way these are displayed is of course subjective, but rust has so nice error messages, which are easy to read and act upon.

For me this "only printing part of the information" combined with rust-analyzer being really slow or not working properly makes the diagnostics window almost useless to me (for Rust). Hence the suggestion of integrating with bacon (perhaps in addition to showing a (filtered) list in the diagnostics pane as it is now).

[jansol]

I would certainly love to see this integrated, along with an Xcode-style inline display mode. The Easy :tm: solution here would be making bacon act as a language server. Then it would be possible to create an extension for running it, and to opt out of rust-analyzer via zed's configuration. I haven't seen any mentions of such efforts or requests in the bacon repo though.

Bacon allows you to pause at any time, something you cannot do with the built-in diagnositcs as far as I know

LSP allows canceling requests AFAIK. Not sure how close that comes to what you are referring to?

[DragonDev1906]

I haven't seen any mentions of such efforts or requests in the bacon repo though.

Probably because the main goal of bacon is being a background process that shows warnings/errors whenever it finds them, rather than being asked by a different process to do something.

I think the closest to a LSP in bacon is the export file, the format of which can be configured: https://github.com/Canop/bacon/blob/c5cd5a72d3cadab15283a6f409db48edda725e3c/website/docs/config.md?plain=1#L127

LSP allows canceling requests AFAIK. Not sure how close that comes to what you are referring to?

I don't know much about how Rust-Analyzer does things. Bacon (as of the latest version) effectively does the following:

• Whenever any of the files are changed: Queue that crate and everything depending on it to the list of things to check
• When currently not compiling/checking anything and not paused: Empty the queue and start checking all the crates that where changed in the background
  • While paused: Just don't start checking, but still fill the queue (all crates there are checked once unpaused).
• If something is added to the queue (default behavior on_change_strategy = "wait_then_restart") bacon finishes checking what it's currently checking, then displays the warnings/errors after compilation finished and checks everything that was added to the queue since (see 2nd point).

Previously checks where canceled automatically/immediately when you changed something else on_change_strategy = "kill_then_restart", which wasn't ideal.

[jansol]

Probably because the main goal of bacon is being a background process that shows warnings/errors whenever it finds them, rather than being asked by a different process to do something.

It could still compute these in the background, the LSP part could be a relatively simple shim that requests the background process to resume (if paused and there have been changes) and to return the cached diagnostics when it has recent enough ones.

[bbb651]

Luckily an LSP implementation already exists! https://github.com/crisidev/bacon-ls

I might try to create a plugin for it. Either way I don't think special support within Zed is a good idea in general, and in this case the diagnostics mutlibuffer with an LSP is already what you're asking for.

[nullstalgia]

Even if there isn't a dedicated plugin for it, a mention on the docs on how to get the two to play nice would be great.

While I really like Zed's diagnostics tab, it doesn't prioritize putting Errors above Warnings, and I can't move it outside of Zed itself. Bacon feels like a good in-between, since it can be on a dedicated window/monitor, but the aforementioned cargo check issues make it feel not-so-seamless.