Panic when editing file with any error in vs code

[andersforsgren]

In vs code on windows (1.19.2, ia32), rls seems to crash rustc as soon as there is an error in the edited file.

The vs code output window shows this backtrace. As long as the file is OK, there is no error logged and RLS seems to work, at least sporadically. Even when the error occurs, RLS often still appears to work (error squiggles appear, navigation seems to work). It's a bit hit & miss, and sometimes it just stops working for no apparent reason (single very simple .rs file cargo project). I can't reproduce the conditionsn that makes it stop working so I'm suspecting the error is somehow related.

thread 'request-worker-3' panicked at 'called `Result::unwrap()` on an `Err` value: DoesNotExist("C:\\Users\\Anders\\.multirust\\toolchains\\stable\\src")', libcore\result.rs:945:5
stack backtrace:
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', libcore\option.rs:335:21
stack backtrace:
   0: std::rt::lang_start_internal
   1: <i64 as std::sys::windows::IsZero>::is_zero
   2: std::panicking::Location::column
   3: std::panicking::Location::column
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic
  10: rustc_save_analysis::SaveContext::get_field_ref_data
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <rustc_save_analysis::CallbackHandler<'b> as rustc_save_analysis::SaveHandler>::save
  17: <unknown>
  18: <unknown>
  19: <log::NopLogger as log::Log>::log
  20: <rustc_driver::pretty::UserIdentifiedItem as core::fmt::Debug>::fmt
  21: <rustc_driver::pretty::UserIdentifiedItem as core::fmt::Debug>::fmt
  22: <rustc_driver::pretty::UserIdentifiedItem as core::fmt::Debug>::fmt
  23: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  24: rustc_driver::driver::compile_input
  25: rustc_driver::run_compiler
  26: <unknown>
  27: <unknown>
  28: _rust_maybe_catch_panic
  29: <unknown>
  30: <<std::sync::rwlock::RwLock<T> as core::fmt::Debug>::fmt::LockedPlaceholder as core::fmt::Debug>::fmt
  31: std::sys::windows::thread::Thread::new
  32: BaseThreadInitThunk
  33: RtlUserThreadStart

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

After the first time this backtrace is shown, subsequent errors will instead have this trace:

thread 'request-worker-3' panicked at 'Once instance has previously been poisoned', libstd\sync\once.rs:315:21
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', libcore\option.rs:335:21
stack backtrace:
   0: std::rt::lang_start_internal
   1: <usize as std::sys::windows::IsZero>::is_zero
   2: std::panicking::Location::column
   3: std::panicking::Location::column
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: std::sync::once::Once::call_inner
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: _rust_maybe_catch_panic
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: _rust_maybe_catch_panic
  20: <unknown>
  21: <<std::sync::rwlock::RwLock<T> as core::fmt::Debug>::fmt::LockedPlaceholder as core::fmt::Debug>::fmt
  22: std::sys::windows::thread::Thread::new
  23: BaseThreadInitThunk
  24: RtlUserThreadStart
stack backtrace:
   0: std::rt::lang_start_internal
   1: <usize as std::sys::windows::IsZero>::is_zero
   2: std::panicking::Location::column
   3: std::panicking::Location::column
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic
  10: rustc_save_analysis::SaveContext::get_field_ref_data
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <rustc_save_analysis::CallbackHandler<'b> as rustc_save_analysis::SaveHandler>::save
  17: <unknown>
  18: <unknown>
  19: <env_logger::filter::Filter as core::fmt::Display>::fmt
  20: <env_logger::filter::Filter as core::fmt::Display>::fmt
  21: <env_logger::filter::Filter as core::fmt::Display>::fmt
  22: <env_logger::filter::Filter as core::fmt::Display>::fmt
  23: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  24: rustc_driver::driver::compile_input
  25: rustc_driver::run_compiler
  26: <unknown>
  27: <unknown>
  28: _rust_maybe_catch_panic
  29: <unknown>
  30: <<std::sync::rwlock::RwLock<T> as core::fmt::Debug>::fmt::LockedPlaceholder as core::fmt::Debug>::fmt
  31: std::sys::windows::thread::Thread::new
  32: BaseThreadInitThunk
  33: RtlUserThreadStart

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.25.0-nightly (3d292b793 2018-02-03) running on x86_64-pc-windows-msvc

The directory mentioned in the backtrace (~.multirust\toolchains\stable) does indeed not exist.

> rls --version
rls-preview 0.124.0-nightly (511321a 2018-01-23)
> rustc --version
rustc 1.25.0-nightly (3d292b793 2018-02-03)
> cargo --version
cargo 0.26.0-nightly (1d6dfea44 2018-01-26) 
> rustup show
Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-2017-12-12-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.25.0-nightly (3d292b793 2018-02-03)

[nrc]

Minimal test case:

struct Foo {
  f: u32,
}

fn new(f: u32) -> Foo {
    Foo { fs }
}

This seems to rely on the field init shorthand, and when there is an error there it causes the compiler to crash while trying to emit the save-analysis data.

[nrc]

Fixed in rust-lang/rust#48007

[andersforsgren]

Oh, it’s related to the specific error of the field name in the initializer? Could have sworn I tried a dozen different types of error and it felt it happened all the time, so I must have forgotten the “xs” error in the initializer when I tried those other errors.
Thanks for the quick response!