Problem finding sysroot #544

nrc · 2017-11-03T21:07:58Z

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 #450 (comment) 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

The text was updated successfully, but these errors were encountered:

cynecx · 2017-11-03T21:33:24Z

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 · 2017-11-03T21:39:32Z

@cynecx do you have a RUSTC env var set?

Xanewok · 2017-11-03T21:44:08Z

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 · 2017-11-03T21:45:36Z

@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 · 2017-11-03T21:52:59Z

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 · 2017-11-03T21:56:25Z

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

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

vorner · 2017-11-04T15:04:43Z

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 · 2017-11-07T05:15:18Z

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 · 2017-11-07T06:43:45Z

@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 · 2017-11-07T09:12:48Z

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 · 2017-11-08T09:50:35Z

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 #544 (comment) 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 · 2017-11-08T11:12:28Z

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

ChristophWurst · 2017-11-08T11:39:51Z

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

mkpankov · 2017-11-08T11:55:45Z

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 · 2017-11-10T08:05:55Z

@colibre works for me.

bklooste · 2017-11-11T04:00:43Z

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

MaxBittker · 2017-11-12T22:35:53Z

rustup update should fix this now

cynecx · 2017-11-12T23:47:37Z

@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 · 2017-11-13T03:17:08Z

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 · 2017-11-13T08:36:35Z

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

colibre · 2017-11-13T21:09:52Z

Works for me after updating.
Probably due to this getting closed rust-dev-tools/rls-analysis#119

nrc added the bug label Nov 3, 2017

GabrielMajeri mentioned this issue Nov 4, 2017

"RLS: working" till the heat death of the universe #548

Closed

oceanusxiv mentioned this issue Nov 7, 2017

statusBar "RLS: working" all the time, spinning continuously rust-lang/vscode-rust#186

Closed

DSpeckhals mentioned this issue Nov 9, 2017

Use of option_env Macro Causing the RLS to Panic? rust-dev-tools/rls-analysis#119

Closed

nrc closed this as completed Nov 13, 2017

jonasbb mentioned this issue Nov 18, 2017

RLS cannot find rustc rust-lang/vscode-rust#190

Closed

Problem finding sysroot #544

Problem finding sysroot #544

Comments

nrc commented Nov 3, 2017

cynecx commented Nov 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Xanewok commented Nov 3, 2017

Uh oh!

Xanewok commented Nov 3, 2017

Uh oh!

cynecx commented Nov 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Xanewok commented Nov 3, 2017

Uh oh!

cynecx commented Nov 3, 2017

Uh oh!

vorner commented Nov 4, 2017

Uh oh!

GabrielMajeri commented Nov 7, 2017

Uh oh!

oceanusxiv commented Nov 7, 2017

Uh oh!

0x7CFE commented Nov 7, 2017

Uh oh!

ChristophWurst commented Nov 8, 2017

Uh oh!

colibre commented Nov 8, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ChristophWurst commented Nov 8, 2017

Uh oh!

mkpankov commented Nov 8, 2017

Uh oh!

king6cong commented Nov 10, 2017

Uh oh!

bklooste commented Nov 11, 2017

Uh oh!

MaxBittker commented Nov 12, 2017

Uh oh!

cynecx commented Nov 12, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DSpeckhals commented Nov 13, 2017

Uh oh!

cynecx commented Nov 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

colibre commented Nov 13, 2017

Uh oh!

cynecx commented Nov 3, 2017 •

edited

Loading

cynecx commented Nov 3, 2017 •

edited

Loading

colibre commented Nov 8, 2017 •

edited

Loading

cynecx commented Nov 12, 2017 •

edited

Loading

cynecx commented Nov 13, 2017 •

edited

Loading