On some projects it somehow invalidates cargo cache

[Ddystopia]

On some of projects, if I use ra-multiplex, it will conflict with cargo. I am often running cargo check even if I can see diagnostics in the editor, and at some projects it will show Blocking waiting for file lock on build directory and then recompile all dependencies. I don't know what should I show you, logs etc, I would like to provide any information if I can.

[pr2502]

Are you sure this is an issue specific to ra-multiplex? We never touch the target directory, this to me sounds like a rust-analyzer issue.

Please try if you can reproduce the issue without ra-multiplex.

[Ddystopia]

I know it is a bit strange, but when I've switched to rust-analyzer, everything vere good. For now I can't access my PC so I would not be helpful

[pr2502]

Hmm, I have another guess. Do you use RUSTC_FLAGS to set some parameters? Contents of RUSTC_FLAGS are used as part of the hash calculation and changing it causes a full rebuild. As it is now ra-multiplex doesn't pass on any env vars to rust-analyzer, cargo check without the RUST_FLAGS set could then cause a full rebuild.

[Ddystopia]

Now I've looked at my shell history in my dotfile repo in GitHub to check it (I won't have access to the PC untill ±6th September so I could not actively participate in finding the possible bug), and I was running cargo clippy with custom arguments on the cli.

I do not remember clearly, but at this time it is possible that I've used #26 PR to pass cargo clippy, and it is possible that it had different cli args.

Sorry for such an incomplete issue and thank you for your work!

[IndianBoy42]

Hmm, I have another guess. Do you use RUSTC_FLAGS to set some parameters? Contents of RUSTC_FLAGS are used as part of the hash calculation and changing it causes a full rebuild. As it is now ra-multiplex doesn't pass on any env vars to rust-analyzer, cargo check without the RUST_FLAGS set could then cause a full rebuild.

I guess that the inheritance of environment variables may continue to be a problem. like the PATH variable problem in #27). Even if we add all the cargo/rust env vars manually, build scripts may look at arbitrary env vars (like checking CC if it builds some native libraries). I wonder if its possible to start the server from the editor/client and then move the ownership to the daemon so it persists after the client stops). That sounds platform specific and complicated.

[pr2502]

I wonder if its possible to start the server from the editor/client and then move the ownership to the daemon so it persists after the client stops.

Not possible on linux, you can only reparent to pid 1, no idea how this works on other platforms but I doubt it.

[Ddystopia]

Just want to post here a workaround: You could just change cargo target dir so they would not invalidate each other