Ship rust-analyzer on stable toolchain?

[ehuss]

As part of a push to make rust-analyzer the official LSP for Rust, I would like to see there is any desire to transition rust-analyzer to be available on the stable Rust toolchain. Currently it is available in the nightly toolchain, which gets updated roughly once a week or two.

I think the primary reason to do this is to make it easier for users to obtain the server binary if they are not using VSCode. Requiring a separate nightly installation may introduce a barrier that could turn people away. It can also signal that rust-analyzer is not stable or reliable, which may be the wrong message for some.
Users can fetch the GitHub Release binaries manually, but that is a bit cumbersome. Other editors could automate this, but it would require a whole separate download mechanism which AFAIK can be a bit awkward.

Additionally, I think there may be a few other platforms that are available in tier 2, though I'm not sure if there is much demand for those.

Reasons against that have been mentioned:

• The rust-analyzer team currently does not have a procedure for backporting critical fixes to a "beta" branch.
• rust-analyzer development is still under rapid development, meaning getting a release that is 6 weeks or more old would be a noticeable drawback, and the user is left with a poorer experience.
  • (pietroalbini points out that using nightly means their installation can be much older since they do not use nightly regularly, and thus don't update it. I think that is probably common as most users are not using nightly.)
• It may increase the rate of reporting duplicate issues, particularly for things that have already been fixed.
• It is unclear (to me) what, if any, demand there is for this.

Does the rust-analyzer team want to make this a thing? Is there a timeline where you would like to see it happen? Or is this something you would prefer to not support for the foreseeable future?

Notes about implementation:

• It might be good to reapply Add rust-analyzer proxy rustup#2408
  • An alternate approach considered in Add --profile empty support rustup#2974 is to not use stable, but use a different rustup delivery mechanism that could be pushed more frequently
• Remove this.
• Update the rustup manifest:
  • Update NIGHTLY_ONLY_COMPONENTS
  • Update add_renames_to

[lnicola]

Additionally, I think there may be a few other platforms that are available in tier 2, though I'm not sure if there is much demand for those.

We do have some users on Free- and OpenBSD. I think they might appreciate binaries for those.

[cuviper]

Additionally, I think there may be a few other platforms that are available in tier 2, though I'm not sure if there is much demand for those.

I think it's a big win to expand to all host platforms. Furthermore, even for those that currently have binaries, they're not matching the compatibility of the rest of the toolchain's platform support, especially when it comes to glibc versioning. The current x86_64-unknown-linux-gnu binary here requires symbol version GLIBC_2.25, while the one in rustup only uses GLIBC_2.9. (Officially we require 2.11, and may bump that in the near future.) That's a pain to manage, but Rust's dist CI will handle that.

Reasons against that have been mentioned:

• The rust-analyzer team currently does not have a procedure for backporting critical fixes to a "beta" branch.

Cargo could serve as a model to develop that procedure. But hopefully, most critical bugs will be caught while it's still in nightly, and beta fixing should be relatively infrequent.

• rust-analyzer development is still under rapid development, meaning getting a release that is 6 weeks or more old would be a noticeable drawback, and the user is left with a poorer experience.

It's not as if the rust-analyzer from a few weeks ago was unusable, nor even a few months ago. If it were that much in flux, we wouldn't be ready to replace RLS yet.

Yes, the release train will take longer for new features and bug fixes to reach users, but that's true of the entire Rust toolchain, and that model has served us well for 7 years now. Users get excited about what's coming up, but they're patient enough, and those who are impatient can use beta or nightly, or keep using a non-rustup binary release.

The longer delay also makes it more likely that issues will be caught before they reach stable.

• (pietroalbini points out that using nightly means their installation can be much older since they do not use nightly regularly, and thus don't update it. I think that is probably common as most users are not using nightly.)

Right, so getting the component to the stable channel would help that, making it contemporary with the toolchain they do use.

• It may increase the rate of reporting duplicate issues, particularly for things that have already been fixed.

Maybe so. That's also true of issues for the compiler and everything else.

• It is unclear (to me) what, if any, demand there is for this.

I personally want it, as mentioned here. You can also see that expectation in this reddit comment chain, with a fair number of upvotes, when the repo moved to rust-lang.

[tmandry]

I help maintain a distribution of the Rust compiler and tooling for building Fuchsia, and I would love to see rust-analyzer officially using the same build and distribution mechanisms as the rest of the tools. That way we can release them according to the same process, instead of having developers individually manage their versions (and e.g. send out a PSA when something breaks the integration with our non-cargo build system).

[Veykril]

Also related to this #12280

[flodiebold]

It's not as if the rust-analyzer from a few weeks ago was unusable, nor even a few months ago.

That's true, but it's also not much more stable or bug-free, even if we would sometimes backport fixes. IMO providing releases on the stable channel would imply more of a stability / bug-free-ness promise than we are in a position to give. The implication of stable channel releases would be that they are the 'correct' choice for someone who cares more about stability and having fewer bugs than about the latest features, but that would not be the case for rust-analyzer.

I am all for having rust-analyzer releases on rustup, but I'm rather uncomfortable with providing releases on the stable channel in the current state.

[cuviper]

Maybe there's a way to get that across in the rust-analyzer installation docs? Something roughly like, "rustup provides a component for rust-analyzer that's contemporary with each stable/beta/nightly toolchain, but this may be missing some current features and bug fixes due to the slower release pace in those channels."

[matklad]

Some thoughts:

• I am pretty sure that at this stage week-long release cycle is an important force multiplier for rust-analyzer. Contributors benefit from seeing their contribution hit prod within a week, maintainers benefit from having to think only about a single branch, users benefit from overall better quality, given the current resource constraints.
• Six-weeks release cycle would make sense by itself when:
  • rust-analyzer shares a lot of code with rustc.
  • there are people willing to put time&attention into backports
• I think it's important that VS Code users continue receiving weekly updates
• I'd love for other editors to implement similar updating functionality as well (eg, I think coc-rust-analyzer has it (IIRC, it was implemented even before support arrived in VS Code)). New users shouldn't know that "you need to install rustup to use rust-analyzer", new-users should just configure their editor.
• rustup is convenient distribution mechanism. For cases where you editor can't just install everything itself, leveraging rustup would be very convenient. Note, however, that you'd have to install editor-specific extension somehow anyway. We are not packaging
• Ideally, rustup would include functionality to just have weekly releases of a tool, but that's obviously quite alien to its curret model

My proposed plan would be to do minimal thing and adjust as necessary:

• Ship some version of rust-analyzer on stable toolchain. Essentially, just upgrade the current workflow for stable as well
• Document that the official way to get rust-analyzer is "consult your editor's documentation"
• For VS Code, use the current distribution mechanism, which involves embedding of rust-analyzer binary with the extension itself
• For other editors (support for which we don't maintain), let it to the extension authors to decide where do they fetch ra from
• Continue weekly release process

If someone finds stable-toolchain rust-analyzer important enough, they can put hours into managing backports and doing QA, but I don't think ra team should proactively work on that at this stage. I do think ra team could stomach additional issue requests due to ra from stable.

[cuviper]

New users shouldn't know that "you need to install rustup to use rust-analyzer", new-users should just configure their editor.

My take is more that new users should get their rust-analyzer from the same place they got the rest of the toolchain. That's most often rustup, but then you're not "installing rustup to use rust-analyzer", you already have it for Rust itself. That could also be from distro packages though, and I hope that most LSP plugins can deal with that as long as it's in the sysroot or PATH. (But I don't expect nor want my editor plugins to learn to invoke distro package managers at all.)

I understand that the VS Code extension is more tightly integrated and probably wants to stay directly in sync, and that's fine.

My proposed plan would be to do minimal thing and adjust as necessary:

• Ship some version of rust-analyzer on stable toolchain. Essentially, just upgrade the current workflow for stable as well

Still with the "preview" suffix, or are you ok with dropping that too? (with add_renames_to as mentioned earlier)

The current draft of the blog post for deprecating RLS says that 1.64 will be its last. We could stage this such that the nightly-only gate is lifted now, letting the "rust-analyzer-preview" component show up in 1.63, and then drop "preview" in 1.64 along with RLS's end. I'm not sure it really matters though, maybe it's just as good to drop "preview" right away.

If someone finds stable-toolchain rust-analyzer important enough, they can put hours into managing backports and doing QA, but I don't think ra team should proactively work on that at this stage.

I expect a lighter touch than "hours" needed -- most toolchain fixes just ride the release train unless they're severe regressions -- but I am willing to help here with my @rust-lang/release hat on.

[ehuss]

It sounds like a good plan to me. I also would not expect there to be much effort in backporting. Cargo averages about 2 backports per release, which takes tens of minutes to deal with.

I also think dropping the preview suffix would be good. It doesn't really seem to be in "preview" mode anymore.

@rust-lang/wg-rls-2 and @rust-lang/release are you OK with the plan of adding rust-analyzer to the stable release? I don't have a particular preference if it shows up in 1.63 or 1.64. I suppose there isn't a particular need to wait.

[pietroalbini]

I am ok with removing "preview" and promoting r-a to the stable channel! (t-release hat)