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.

[tshepang]

needs another approval...

[thaliaarchi]

I'm interested in this, so I manually applied the changes, but with the directory build/rust-analyzer/. I think there's some hardcoded assumptions for build/ in bootstrap:

Traceback (most recent call last):
  File "x.py", line 53, in <module>
    bootstrap.main()
  File "src/bootstrap/bootstrap.py", line 1393, in main
    bootstrap(args)
  File "src/bootstrap/bootstrap.py", line 1360, in bootstrap
    build.build_bootstrap()
  File "src/bootstrap/bootstrap.py", line 1026, in build_bootstrap
    args = self.build_bootstrap_cmd(env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "src/bootstrap/bootstrap.py", line 1143, in build_bootstrap_cmd
    raise Exception("no cargo executable found at `{}`".format(self.cargo()))
Exception: no cargo executable found at `build/rust-analyzer/x86_64-unknown-linux-gnu/stage0/bin/cargo`

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tshepang]

@thaliaarchi have you tried with build-rust-analyzer

[fee1-dead]

Please use [@]rustbot ready to indicate that your PR is ready for review next time

@bors r=Mark-Simulacrum,fee1-dead

[bors]

📌 Commit 24144ff has been approved by Mark-Simulacrum,fee1-dead

It is now in the queue for this repository.

[Zalathar]

Bors hasn't noticed that this was merged.

@bors r-