Document fixes / workarounds for rust-analyzer breaking incremental recompiles

[alice-i-cecile]

A user ran into this problem after following the linked advice on fast compiles.

I'm not entirely sure on the best solution.

We could:

1. Suggest that they change the target directory for rust-analyzer, using https://github.com/rust-lang/rust-analyzer/pull/15681
2. Suggest they use sccache to share build artifacts (very useful when playing with many Bevy projects).
3. Use the workarounds listed here.
4. Do something else that I haven't thought of! I'm not a compiler/build tools wizard 😅

[alice-i-cecile]

Presumably this is a problem for other Language Server Protocols (LSPs) as well. rust-analyzer is the one I'm most concerned about though, as new programmers tend to use VSCode and have less capacity for troubleshooting this sort of thing on their own.

[IceSentry]

I think sccache and setting the targetDir config to true should both be recommended but starting with the targetDir suggestion first. sccache is just a nice bonus on top. The targetDir fix should also help with rust-analyzer locking cargo commands for too long.

[ethanniser]

A user

Thats me! Ended up trying option 1

in settings.json

"rust-analyzer.rust.analyzerTargetDir": true

and everything seems to be working fine now

[paul-hansen]

You can also tell rust analyzer to use the same features you are using with cargo run. (Usually bevy/dynamic_linking) that way it's able to reuse build artifacts between them. That has the advantage of not doubling the size of the target directories on disk, but the drawback of sometimes locking the build until it finishes, the build will be faster when it does run though. I have an answer here that goes over how to do the features in clion (rustrover should be similar) and vscode: https://stackoverflow.com/a/75561975

I personally started using the separate build directory, but I have seen people complain about the size of the target directory before so I'm not sure doubling it is ideal for everyone.

[musjj]

sccache looks interesting. Does it actually solve any compilation issues or is it just for saving drive space?

So I'm seeing two approaches here:

1. Have a separate directory for rust-analyzer output and use sccache to drive down the space consumption.
2. Share the --feature bevy/dynamic_linking flag with rust-analyzer and your debugger. Maybe rust-analyzer.cargo.features would be useful here?

[paul-hansen]

Sscache doesn't cache incrementally compiled crates, which for debug builds by default means your project crate and any path dependencies. It also doesn't work for dynlib crates, so not bevy if you use dynamic_linking. Source: https://github.com/mozilla/sccache#rust So I think it's pretty minor benefit for debug builds. Could be interesting to get some comparison numbers though. You would want to do one of the other two approaches in addition to sscache anyway since it would still have to pull the different results from the cache into your target directory each time.

So imo sscache is not really a good solution to this problem, just might make the conflict resolution happen quicker and is limited at doing that. The other two approaches prevent the conflict.