rls behaviour depends on its current directory when using rustup

[Trolldemorted]

If you use rustup with the stable toolchain as the default one, and create an override for a project, all rust/cargo commands in that directory use the overwritten toolchain.

However, rls does apparently not use the appropriate toolchain for overridden root directories - when i send a rootPath (which is rustup-overridden) in the InitializeParams, rls sends a publishDiagnostics message with errors:

{
	"jsonrpc": "2.0",
	"method": "textDocument/publishDiagnostics",
	"params": {
		"uri": "file:///C:/Users/Benni/repositories/rls/test_data/rename/src/main.rs",
		"diagnostics": [{
			"range": {
				"start": {
					"line": 0,
					"character": 0
				},
				"end": {
					"line": 0,
					"character": 0
				},
				"label": null
			},
			"secondaryRanges": [],
			"severity": 1,
			"code": "E0462",
			"source": "rustc",
			"message": "found staticlib `std` instead of rlib or dylib\n\nhelp: please recompile that crate using --crate-type lib\nnote: crate `std` path #1: C:\\Users\\Benni\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\std-0a78323911070f99.dll.lib\nhelp: please recompile that crate using this compiler (rustc 1.20.0-nightly (445077963 2017-06-20))\nnote: crate `std` path #1: \\\\?\\C:\\Users\\Benni\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-0a78323911070f99.rlib compiled by \"rustc 1.18.0 (03fc9d622 2017-06-06)\"\nnote: crate `std` path #2: \\\\?\\C:\\Users\\Benni\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\std-0a78323911070f99.dll compiled by \"rustc 1.18.0 (03fc9d622 2017-06-06)\"\nnote: crate `std` path #3: \\\\?\\C:\\Users\\Benni\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-d367c3ba0db49600.rlib compiled by \"rustc 1.18.0 (03fc9d622 2017-06-06)\""
		}]
	}
}

However, if rls' execution directory is a directory (not neccessarily the project root, any will do) which is also set to nightly, everything works as expected.

[nrc]

The RLS only works with nightly toolchain. If you try and use a stable toolchain everything will break because the versions of dylibs the RLS tries to link against will be wrong. I'm not exactly sure of the ins and outs of using Rustup like you are doing, so I'm not sure if it should be causing problems like this.

[Trolldemorted]

I understand that rls works only with the nightly toolchain - both rls and my test project are set up to use the nightlies.

The problem is that RLS does not care which toolchain is configured for the project, and uses the one configured for the current directory of the rls process instead.

[Diggsey]

I'm not sure the RLS can do much about this - the toolchain is decided at the point where the RLS process is run, because that's when rustup intercepts the command. The RLS itself, and other tools like rustc and cargo, are unaware of the existence of rustup.

[Trolldemorted]

@Diggsey Why is that? All rls has to do different is defer initializing itself until a initialize request is received, change the working directory to the project root, and then initialize, hasn't it?

[Diggsey]

No, the RLS doesn't choose the toolchain - by the time the RLS is running, the toolchain has already been selected and cannot be changed (because each toolchain has its own RLS)

[Trolldemorted]

But why? I thought there is no rust runtime, and executables generated by rustc are just normal binaries. How is the toolchain relevant to a compiled binary at runtime?

Are these binaries unable to run on systems where no or a different toolchain is installed?

[nrc]

@Trolldemorted rls is a bit unusual in that it dynamically links against the compiler which is part of the toolchain.

[Trolldemorted]

So except writing a wrapper that will start up rls only after the init request was received there is nothing non-hackish we can do (i assumed before that rls was a wrapper for the analyser/compiler)?

Statically linking is not an option?

Related: rust-lang/rustup#765 (comment)

[Trolldemorted]

@nrc I spent some more time on this issue today:

• this is not related to wrong dynamic linking
• my PATH only includes the nightly toolchain's \bin, and ProcMon confirms that all my spawned rls processes load the same .dlls from \.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin
• despite that, the output depends on the working directory

A quick glance at rls-analysis:

• Here you start rustc
• rustc inherits the working directory

=> for rustup users with stable default, rls will be dynamically linked against the installed nightly toolchain (because its in PATH), could have been built with a different version of the nightly toolchain (since rust override allows you to select a certain version of the nightly toolchain), and starts rustc from the stable toolchain.

Changing the working directory before responding to the initialize request would help with this a lot.

[nrc]

Changing the working directory before responding to the initialize request would help with this a lot.

Changing or relying on the working directory has caused us many problems in the past. I'd be pretty uncomfortable relying on it again. It is unfortunate that we don't refer to the right rustc in rls-analysis though. However, I don't think it is that which is causing the error - that is only used to find the location of the sysroot to find save-analysis data, not for building.

How are you running the RLS? Via VSCode? RLS should be started with the equivalent of rustup run nightly rls. I'm not really sure what the root path is doing or really what is happening.

[dbeckwith]

Any update on this? I'm running into this problem now where RLS is using sources from stable (my default toolchain) when completing code in a project using a pinned nightly (using the rust-toolchain file). If RLS used the current directory to determine the proper toolchain I think that would fix it for me.