[Discussion] Approach for supporting older versions of rustc

[KOLANICH]

As it was recommended in #9629, I open the issue.

As we all know, distros (I mean Debian-based distros, such as Ubuntu and Debian itself) have problems with supplying the most recent versions of rust in time.

While it is possible to use the stuff like rustup and curl ... | sudo bash, it can have some issues and so it is strongly disrecommended.

So, an issue arises to allow outdated versions of rust to build rust-analyser.

There are some options:

• introducing a policy of keeping the code compatible to the oldes version of rustc available in the latest versions of all major distros. Pro - rustc built by the distro itself can be used. Con - limiting oneself to old features only is not fun.

• making an own update server for package managers and hosting it on GitHub Pages. Provide the prebuilt binary packages for the latest rust-nightly via it. Con - trust and security issues. Pro - latest Rust.

• making an additional branch for each rust release significantly present in distros, that is meant to be rebased over master and gets a commit fixing the incompatibility when a commit not supporting needed versions of rust is landed into master. An example of such a branch is https://github.com/KOLANICH-toosl/rust-analyzer/tree/ubuntu_21.04_compat . Con - additional work for ones maintaining this branch. Pro - developers get more fun playing with the fresh features. Comment - it'd be easier to maintain such a branch if the introduction of incompatible changes is documented. Also it may be possible to setup a GitHub action automatically rebasing the branch over master and detecting the incompatible commits.

[lnicola]

CC #9550

[jonas-schievink]

Personally I don't think we should go out of our way to cater to distros that ship outdated Rust version. They can easily ship a just-as-outdated rust-analyzer if they insist.

In fact rust-lang/rust already has an experimental rust-analyzer submodule that should roughly match the Rust version, so that can be used as a starting point for finding a good release.

[lnicola]

To put it differently, Debian could package rust-analyzer from the in-tree version, like it does with rustfmt or clippy (actually, these aren't even available in unstable, you need to enable the experimental repo).

Of course, that version might not be perfectly compatible with the Code extension, but if you want that, it can download its own RA binary.

[flodiebold]

Also, it's worth noting that it's not about "fun playing with fresh features". One issue is that we interact with rustc (e.g. running proc macros built by it), and supporting older versions as well as the current one would mean more effort and more code to maintain. The second issue is that we're working towards using libraries shared with rustc, and it's hard enough to argue for those libraries to build on current stable. Currently the rustc codebase uses lots of nightly-only features; there are many reasons for this other than developer fun, for example being able to dog-food and test new features.