internal: remove support for pre-1.47 sysroots

[lnicola]

This changed in 1.47 (about a year ago), so it should be pretty safe to remove.

bors r+

[bors]

Build succeeded:

• Rust (macos-latest)
• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript (ubuntu-latest)
• TypeScript (windows-latest)

[SamB]

Unfortunately, c2rust is still using nightly-2019-12-05 (rustc 1.41.0-nightly (6d77e45f0 2019-12-04)) for some reason, but the commit before, 9724ca7, seems to work fine...

[lnicola]

Sorry for that. Do you think there are any chances for c2rust to upgrade to a more recent version?

[TonalidadeHidrica]

Hello. I want to use rust-analyzer with Rust 1.42.0. (This is because I enjoy competitive programming in AtCoder, in which the judge server uses Rust 1.42.0.) Is there a way to use rust-analyzer with 1.42.0?

I tried manually setting RUST_SRC_PATH to /Users/username/.rustup/toolchains/1.42.0-x86_64-apple-darwin/lib/rustlib/src/rust/src/, but failed, because when specifying RUST_SRC_PATH directly, a directory named core should exist right under the path (which is checked here), but pre-1.47 source has a directory libcore instead of core, and the assertion fails. Will it be alright if the assertion is relaxed so that it checks the existence of either libcore or core? Or is pre-1.47 version completely ruled out for rust-analyzer use?

[lnicola]

@TonalidadeHidrica I'm already sure you know all these options, but I'll list them anyway:

• we can revert this change
• you can keep using an older version of RA
• you install a newer version of Rust and hope or take care not to use newer APIs or language features; in competitive programming I expect this to work relatively well, and AtCoder doesn't penalize you for programs that don't build
• you write code on a newer version of Rust, but test with cargo +1.42 run; you can use a different target directory to prevent extra rebuilds
• you use a helper like cargo-compete

I'm not against reverting (I'm actually tempted to), but we can't realistically support toolchains for such a long time. The official policy is to only support the latest version, although in practice older ones work too. I wouldn't be surprised if other functionality (besides proc macros) was already broken in 1.42.

It also depends on whether you're using Rust for anything else. If you are, you should probably be using stable.

[TonalidadeHidrica]

@lnicola Thanks for all your kind, detailed advice. I'm aware that we cannot essentially support all the old versions forever. Also it's a good idea to use cargo +1.42 run. I'll go for that option.

[ariva]

@TonalidadeHidrica This hacky "fix" might help you:
cp -r $(rustc --print sysroot)/lib/rustlib/src/rust/src $(rustc --print sysroot)/lib/rustlib/src/rust/library
or
ln -s $(rustc --print sysroot)/lib/rustlib/src/rust/src $(rustc --print sysroot)/lib/rustlib/src/rust/library

[grantperry]

G'Day!
I fall into a similar situation as @TonalidadeHidrica. We cross compile for a custom platform we bought up internally, based on 1.42. It would not be feasable to ever update our CC'd toolchain. It would be nice if RA worked out of the box for pre-1.47 sysroots.

I had already figured out the solution @ariva suggested, which works.

Does rolling back this change have any determent other than allowing support for pre-1.47 sysroots?

[lnicola]

@grantperry officially we only support the latest stable version. The idea is that we don't want to keep piling hacks in RA to keep it working with toolchains that even the Rust project doesn't have resources to support (with 30x or so more active developers), and 1.42 is almost two years old at this point. I wouldn't want to signal "yes, we'll support X-years old toolchains".

We already break this stance for proc macros. We have four implementations: 1.47 (or earlier?), 1.54, 1.56 and 1.58. Does the 1.47 code work on 1.42? I don't know, but I'm pretty sure we wouldn't want to fix bugs about popular crates like Rocket not working on that version. Also, each of these adds a bit of run-time and about 24 MB RAM to our analysis-stats metrics, possibly hiding some regressions (although admittedly, these are somewhat noisy).

And it's not just macros. Does type inference work for ? and the Try trait? Every couple of Rust versions some language item changes and I'm not sure whether the fixes remain compatible with the previous definitions of them.

So reverting this PR wouldn't hurt us, but it would be a precedent for when someone wants to use the latest RA with Rocket on a nightly Rust 1.33, or whatever.

[grantperry]

@lnicola I do see the precedent this would set now, and I agree that it would be unreasonable to uphold. Thanks for your support!