What is the recommended way to install & update rust-analyzer on macOS?

editors and IDEs
1

As the title says, what is the generally recommended/intended/best way to install rust-analyzer on macOS, especially if I want weekly updates? I was originally installing it via Homebrew, but that required moving ~/.cargo/bin to the end of my PATH to keep the rust-analyzer stub therein from taking priority over Homebrew's binary. When I asked about the stub on /r/rust, I was told that rust-analyzer should be installed through rustup instead. I did that, but now (as of Rust 1.92) I have a different problem: Whenever I open a Rust source file while in a subdirectory of a Rust project, a misplaced target/ directory (containing just rust-analyzer/flycheck0/{stdout,stderr}) gets created in that subdirectory, cluttering things up. I suspect that rust-analyzer fixed this bug in the next weekly release, but rustup only seems to provide rust-analyzer versions corresponding to rustc releases, so I'm currently on track to be stuck with this behavior until January 22.

Is there a way to force rustup to install the latest weekly release of rust-analyzer, even if there hasn't been a rustc release to go with it? If not, why shouldn't I just switch back to installing via Homebrew? Is there a better way to install rust-analyzer?

2

You can use nightly rustup. It will still not be weekly, but it will be faster to update than using stable (essentially, it updates when someone manually does a sync from rust-analyzer to rust-lang/rust, and that happens from time to time, I believe somewhat like weekly but its @lnicola doing the syncs).

Of course if you're using VSCode you should use the extension's auto-downloaded rust-analyzer. I believe Zed can also do that.

3

How, exactly? I tried uninstalling the current rust-analyzer with rustup component remove rust-analyzer and then installing for nightly with rustup component add --toolchain nightly rust-analyzer, but then running rust-analyzer -V gave the error "Unknown binary 'rust-analyzer' in official toolchain 'stable-x86_64-apple-darwin'." If I have to set my default toolchain to nightly to use nightly rust-analyzer, I'm not going to do it.

4

You need to invoke r-a with rust-analyzer +nightly.

5

I'm using Vim with the ALE plugin for LSP support, and it doesn't seem to have a way to pass custom arguments to rust-analyzer. I can set the path to rust-analyzer and set the rust-analyzer configuration, and that seems to be it.

6

Well, that's where my knowledge ends :sweat_smile: I don't know Vim.

7

Yeah, they're weekly unless I'm travelling or something goes wrong. We backport some fixes during the beta period, but you're unlikely to see a toolchain point release for a rust-analyzer fix.

You can set a path like ~/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/rust-analyzer or write a shell script that runs exec $(rustup +nightly which rust-analyzer).

rustup +nightly component remove cargo rust-std rustc rust-src will make updating faster -- it appears to crash in some cases, but it looks benign.

8

If I'm at the point where I'm writing a shell script wrapper for rust-analyzer, I have to ask: Why should I install rust-analyzer via rustup instead of Homebrew in the first place? Is the needed PATH muckery the only reason, or is there another reason?

9

I'm not really familiar with Homebrew, but there's nothing in r-a that requires you to use rustup. The proxy installed by the latter used to be pretty annoying, but these days it's optional:

warn: tool rust-analyzer is already installed, remove it from ~/.cargo/bin, then run rustup update to have rustup manage this tool.

10

What command did you run that produced that warning? My experience has been that running rustup update after deleting ~/.cargo/bin/rust-analyzer just brings the stub back.

11

Right, I'm not deleting it, I just have the file. Maybe try replacing it with a symlink to the Homebrew one.

12

This is just an opinion but I prefer rust analyzer installed with via rustup.

rustup toolchain add rust-analyzer and whenever needed run rustup update. And if needed user +nightly toolchain override (before the toolchain bit).

Rust analyzer is only guaranteed to run well if it is using all tools from the same toolchain version.

By using ALE or brew they will be out of sync.

PS also not correct you need default nightly to use nightly rust analyzer. You can use stable toolchain in projects and nightly rust analyzer for formatting afaiu.

This can be done by using +nightly in neovim or vim config for the rust analyzer LSP (on mobile now so can not copy mine sorry.)

13

OK, I replaced the stub at ~/.cargo/bin/rust-analyzer with a symlink to Homebrew's rust-analyzer, and then running rustup update produced the warning you showed. If rustup update is going to warn that it doesn't like me mucking with its stubs like this every time I run it, I'd rather not do it.

14

I would like to see how you're doing this in Vim.

15

Try removing the rustup component if you use Homebrew.

16

I did rustup component remove rust-analyzer, but rustup update still gives the same warning.

17

The next version of rustup has a feature where other rust-analyzer binaries with lower priority (i.e. later) than the shim in the current PATH environment will be used as a fall-back when the currently selected toolchain doesn’t have a rust-analyzer component. The new version is currently in beta, so you could try it out using

RUSTUP_UPDATE_ROOT=https://dev-static.rust-lang.org/rustup rustup self update

Also, you can use

rustup set auto-self-update disable

to avoid rustup downgrading itself back to the latest stable version on your next invocation of rustup update without that environment variable set.[1]

  1. Make sure to enable it again once the actual release of rustup 1.29.0 happens, so you don’t miss future updates.

    Also that stable version may then contain further patches, though I’m not 100% certain that this update (from beta-released to stable rustup) will actually install automatically.

    If it doesn’t, that might be worth an issue though :thinking: ↩︎

1 Like
18

One thing you can do here is create a directory of your own with whatever binary or symlink you like, and put that directory in your PATH before .cargo and before Homebrew’s directory, to customize which binary is executed per individual command name. There is no reason PATH has to only contain directories somebody else thought up.

19

At this point, I think I'll just wait for this to land.

20

This is what I would try in that situation:

  • Avoid brew for installing both rustup and rust-analyzer
  • Double check rust-analyzer isn't installed by some plugin manager (I don't know if ALE could be doing this). Users mistakenly install from Mason I think and this gives version mismatch problems (between plugin-installed rust-analyzer and toolchain).
  • Check for logs of your LSP state, the goal is to match rust-analyzer's version with the toolchain version.

Besides, some commands we can use to check for any inconsistency are rustup show for the active toolchain (also must match rust-analyzer --version) and both whereis <bin_name> to make sure they are not from brew (shouldn't be in the Cellar).

What I was hinting at with the toolchain versions and the override is mentioned in the rust analyzer guide:

The first part is when rust-analyzer is out of sync with toolchain (which can happen when you install through brew)

rust-analyzer will attempt to install the standard library source code automatically. You can also install it manually with rustup.

$ rustup component add rust-src

Only the latest stable standard library source is officially supported for use with rust-analyzer. If you are using an older toolchain or have an override set, rust-analyzer may fail to understand the Rust source. You will either need to update your toolchain or use an older version of rust-analyzer that is compatible with your toolchain.

The second part, is to configure this from any of your lsp configuration managers (I use neovim's lspconfig, so can't help unless you want that config) but here is the guide's remark:

If you are using an override in your project, you can still force rust-analyzer to use the stable toolchain via the environment variable RUSTUP_TOOLCHAIN. For example, with VS Code or coc-rust-analyzer:

{ "rust-analyzer.server.extraEnv": { "RUSTUP_TOOLCHAIN": "stable" } }

Just use nightly there (This may cause trouble, but I've not had any. I used it to enable rustfmt's unstable flags but I can't confirm now, I stopped using MacOS a month ago, since the GDB experience was not good.)

If you want weekly updates in my view install through rustup, and run it weekly, I've not used cron on MacOS but something of that sort should be fine. I assume a .zshrc script could also do it (like if the number of the day is modulo 7 run rustup update)

PS: also, for the weekly updates, if you are aiming at nightly, I think it should almost always update all components, but could be wrong.