$ ls -l $(where rls)
lrwxrwxrwx 1 root root 65 Jan 1 1970 /run/current-system/sw/bin/rls -> /nix/store/2syaznc6mbxyfhdds8fdq8svjwp8mx7z-rustup-1.21.1/bin/rls
$ rls
error: command failed: 'rls'
error: caused by: No such file or directory (os error 2)
$ rustup component add rls rust-analysis rust-src
info: component 'rls' for target 'x86_64-unknown-linux-gnu' is up to date
info: component 'rust-analysis' for target 'x86_64-unknown-linux-gnu' is up to date
info: component 'rust-src' is up to date
$ rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
stable-x86_64-unknown-linux-gnu unchanged - (error reading rustc version)
info: cleaning up downloads & tmp directories
That message saying “error reading rustc version” is suspicious but I don’t know what to do with it…
Yeah, rustup does binary patching exactly once at install time. When the linker used for that patching vanishes, the rustup managed binaries will also stop working.
A workflow that is slightly more prefered and still considers your tool-chain.toml is described by @viperML in this blogpost: