make rust-analyzer use a dedicated build directory

[tshepang]

inspired by #132794

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

I feel like this was discussed #general > ✔ Setup multiple editors for work on standard lib? @ 💬 but I don't remember why we used a top-level build-rust-analyzer/ as opposed to nesting inside of build/... @Zalathar do you happen to remember why? (It's been a while)

[jieyouxu]

Oh I think it just happens to be an option that works.

[Zalathar]

It has unintuitive interactions with x clean and caching, for example. IIRC x clean won’t delete your download cache, but it will delete your nested RA download cache, because it’s just indiscriminately deleting a subdirectory it doesn’t know about.

If people choose to inflict those risks on themselves, fine, but I don’t think a nested RA build directory is a responsible default.

[jieyouxu]

Oh right. I think that's the caveat I was vaguely recalling...

[tshepang]

would it be good to get x clean not delete what it does not recognize

[mati865]

Or even just avoid deleting build/rust-analyzer.

[Zalathar]

would it be good to get x clean not delete what it does not recognize

Bootstrap “owns” the build directory, so I think it's reasonable for x clean to delete anything it doesn't know about, on the assumption that it's junk left over from an earlier version of bootstrap.

Or even just avoid deleting build/rust-analyzer.

IIRC, one of the motivations people commonly cite for using build/rust-analyzer is that they want x clean to also clean their RA build directory. (And it does accomplish that, as a consequence of deleting build/rust-analyzer entirely.)

[Zalathar]

Anyhow, I strongly agree that our default IDE configs really should be using a separate build dir (e.g. build-rust-analyzer).

[tshepang]

I recently found that x clean does not in fact remove build/rust-analyzer

[Mark-Simulacrum]

Could you file a compiler MCP for this? I'd like to see some more eyes on this before we move in this direction.

[lolbinarycat]

This won't actually work reliably due to a bug in rustic: emacs-rustic/rustic#105

[Mark-Simulacrum]

That seems specific to emacs?

r=me on the change itself once MCP is approved.

[lolbinarycat]

Ah, right, this will still improve things for other editors (this PR was linked to me as "changing the default for emacs"), so there's no point blocking it on emacs being fixed.

[tshepang]

the MCP is now accepted and the pr updated to match

[tshepang]

made the move to build-rust-analyzer/ more comprehensive... it did not cover rustfmt and procmacro settings

should be ready now @Mark-Simulacrum

[fee1-dead]

I'm not sure this is actually the right approach. Doing so makes it so that when rust-analyzer runs x check and we try to run x test or something similar makes rustc run parallel. This will then just lead to a lot more resource usage and potentially freezes and other stuff.

A better approach might be to have some shim binary (or bootstrap option) that oversees rust-analyzer processes and aborts any work in progress when it detects an actual user-run command is waiting to acquire the lock.

[lolbinarycat]

@fee1-dead I'm not sure that fixes the other issue this fixes, which is cache corruption, which was happening to me really often, causing changes to source code to not update the behavior of the final binary.

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit fdd2352 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

☔ The latest upstream changes (presumably #143888) made this pull request unmergeable. Please resolve the merge conflicts.