Rls: Problem finding sysroot

[nrc]

thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', src/libcore/option.rs:839:4

Reported in https://github.com/rust-lang-nursery/rls/issues/450#issuecomment-341650701 by @cynecx

Might be an issue with the client setting up a bad environment, or it might be some bug in the RLS.

@cynecx Could you get a backtrace and try running with logging please? Details about logging are in https://github.com/rust-lang-nursery/rls/blob/master/debugging.md

[cynecx]

What I did:

export RUST_LOG=rls=debug
export RUST_BACKTRACE=1
open -a "Visual Studio Code"

Content of rls.log:

DEBUG:rls::server: Language Server starting up. Version: 0.122.0-nightly (48fd42f 2017-11-01)
DEBUG:rls::actions::post_build: reload analysis: "/Users/paul/dev/test2"
thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', src/libcore/option.rs:839:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::option::expect_failed
  10: rls_analysis::loader::sys_root_path
  11: rls_analysis::raw::read_analysis_incremental
  12: <rls_analysis::AnalysisHost<L>>::reload_with_blacklist
  13: <rls_analysis::AnalysisHost<L>>::reload_from_analysis
  14: <rls::actions::post_build::PostBuildHandler<O>>::reload_analysis_from_memory

The project is a basic project with one source file, main.rs which contains:

mod internals {
    pub fn test() -> u32 {
        print!("")
    }
}

fn main() {
    internals::test();
}

What I've also noticed is, that it doesn't properly show that there is a type violation in fn test() (I guess, this is a different issue right?).

[Xanewok]

@cynecx do you have a RUSTC env var set?

[Xanewok]

I'm guilty of "simplifying" that logic and only now I realized I changed the semantics - previously it attempted to extract the sysroot using command at RUSTC and on any error (not only lack of RUSTC) it tried to do the same, only with rustc command. (Sorry @nrc!)

Maybe that's the root of the problem?

[cynecx]

@Xanewok Yes, it's currently set to RUSTC=/Users/paul/.cargo/bin/rustc, although, even without, it shouldn't be a problem, right?, because rustc is resolvable through the PATH env-variable.

[Xanewok]

Does /Users/paul/.cargo/bin/rustc --print sysroot work then? RLS tries to call a command at $RUSTC as the command (instead of rustc) if it's set to retrieve sysroot info, maybe that's the issue.

[cynecx]

@Xanewok Yes, it does work. The print sysroot command prints:

/Users/paul/.rustup/toolchains/nightly-x86_64-apple-darwin

[vorner]

I have the same problem. I have rustc in path, I don't have RUSTC nor SYSROOT environment variables set (which is different from above). The log then contains some more backtraces, about mutex poisoning (I guess that just follows up).

The funny thing is, this doesn't really seem to matter much to RLS ‒ it works even after that backtrace. I wouldn't have noticed if I didn't look into the log for other reasons.

[GabrielMajeri]

Until this gets fixed, it seems hecaex's fix found in this comment still works.

Set the "rust.build_lib" setting to true in your settings.json and it stops throwing errors.

[oceanusxiv]

@GabrielMajeri unfortunately I just tried this, and at least using the latest nightly Rust this does not in fact stop it from throwing errors

[0x7CFE]

In my case setting rust.buildlib leads to another error:

thread 'main' panicked at 'byte index 16184 is not a char boundary; it is inside 'З' (bytes 16183..16185) of `                                                                                     
`[...]', /checkout/src/libcore/str/mod.rs:2232:4

[ChristophWurst]

I'm facing the same problem. RLS stopped working a few days ago, first discovered when I saw "RLS: working" as described in #548.

DEBUG:rls::server: Language Server starting up. Version: 0.123.0-nightly (9ad92e1 2017-11-06)
DEBUG:rls::actions::post_build: reload analysis: "/home/christoph/…"
thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', /checkout/src/libcore/option.rs:839:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:69
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:58
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::option::expect_failed
             at /checkout/src/libcore/option.rs:839
  10: <rls_analysis::loader::CargoAnalysisLoader as rls_analysis::loader::AnalysisLoader>::search_directories
  11: rls_analysis::raw::read_analysis_from_files
  12: <rls_analysis::AnalysisHost<L>>::reload_with_blacklist
  13: <rls_analysis::AnalysisHost<L>>::reload_from_analysis
  14: <rls::actions::post_build::PostBuildHandler<O>>::reload_analysis_from_memory

The proposed workaround https://github.com/rust-lang-nursery/rls/issues/544#issuecomment-342378003 did not solve the issue here.

RUSTC and SYSROOT were not set. However, rustc is in my PATH.

My setup:
racer 2.0.12
rls-preview 0.123.0-nightly (9ad92e1 2017-11-06)
rustc 1.23.0-nightly (ee2286149 2017-11-07)
Code 1.17.2 b813d12980308015bcd2b3a2f6efa5c810c33ba5
Arch Linux

[colibre]

Substituting a compiled binary directly from the git repository solves the problem. There must be something wrong with the version rustup installs.

[ChristophWurst]

@colibre I can confirm that this "fix" works.

[mkpankov]

For me, copying rls over borks rustup installation completely. rustup doesn't start because it doesn't find required libraries (like libsyntax-xxxx.so).

[king6cong]

@colibre works for me.

[bklooste]

Same problem here Ubuntu 17.2 ..not comfortable with the "fix" print sysroot is also correct .

[MaxBittker]

rustup update should fix this now

[cynecx]

@MaxBittker Nope. It's still spinnin'. Re-compiling rls and replacing the binary solves the issue.

EDIT: Stacktrace

thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', /checkout/src/libcore/option.rs:878:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:57
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::option::expect_failed
             at /checkout/src/libcore/option.rs:878
  10: <rls_analysis::loader::CargoAnalysisLoader as rls_analysis::loader::AnalysisLoader>::search_directories
  11: rls_analysis::raw::read_analysis_from_files
  12: <rls_analysis::AnalysisHost<L>>::reload_with_blacklist
  13: <rls_analysis::AnalysisHost<L>>::reload_from_analysis
  14: <rls::actions::post_build::PostBuildHandler<O>>::reload_analysis_from_memory

[DSpeckhals]

1.23.0-nightly (79cfce3d3 2017-11-12) has the RLS fixes in it. @cynecx, Can you run rustup run nightly rls --version and reply back with the output? Running that with 2017-11-12 should output:

rls-preview 0.123.0-nightly (015073b 2017-11-10)

If it does print that, it may be that your client (like VS Code) is using a non-working RLS version.

[cynecx]

That's strange, I've just run rustup update again and it seems it's working now.

[colibre]

Works for me after updating.
Probably due to this getting closed https://github.com/nrc/rls-analysis/issues/119