tracking issue: crashing/not working

[nrc]

• windows rls stderr: thread 'main' has overflowed its stack #838 - Stack overflow or crash, windows only
• RLS only compiles the first member of a Cargo workspace #876 - Only building one workspace when others are modified.
• RLS nightly not working #756 - RLS nightly not working - after update, restored by changing settings, maybe fixed now.
• Out of bounds indexing panic in save_analysis #755 - Out of bounds indexing panic in save_analysis - maybe fixed by tuple indexing fix
• span_bug inside of DumpVisitor #754 - span_bug inside of DumpVisitor
• "Out of order or duplicate change" panic #752 - "Out of order or duplicate change" panic - large workspace project causing out of order didChange (2ff1669)
• 'called Option::unwrap() on a None value' in SaveContext::get_expr_data #751 - 'called Option::unwrap() on a None value' in SaveContext::get_expr_data - save-analysis error after a compile error
• Constant PoisonErrors #750 - Constant PoisonErrors - + 100% CPU
• VFS: BadLocation #749 - VFS: BadLocation - error committing to VFS: BadLocation, presumably an out of order didChange
• assertion error: c.num == crate_map.len() as u32 #729 - assertion error: c.num == crate_map.len() as u32 - due to implicit extern crate. I have a partial fix locally, but blocked on a compiler fix
• Format on save frequently reverts changes or inserts garbage if you save while analysis is running #718 - Format on save frequently reverts changes or inserts garbage if you save while analysis is running - mysterious out of order error
• Most features don't work on one of my projects #440 Nothing working, may be out of date now

[nrc]

TODO - there are a bunch of similar bugs reported in the rls-vscode repo

[Diggsey]

Updated RLS to latest version as of today, here's a selection of errors from the logs:

ERROR 2018-04-15T15:33:00Z: racer::cargo: ERROR!: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." } C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\racer-2.0.13\src/racer\cargo.rs 492

thread 'request-worker-2' panicked at 'byte index 18446744073709551615 is out of bounds of `extern crate rouille;

extern crate dotenv;
extern crate chrono;
extern crate pretty_env_logger;

extern crate threadpool;

extern crate webhooks;
#[macro_use]
extern crate failure;


use std::{thread, env};
use std::time::Duration;
use std::sync::Arc;
use`[...]', libcore\str\mod.rs:2240:9

thread '<unnamed>' panicked at 'missing key in compiler_jobs', libcore\option.rs:916:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', libcore\result.rs:945:5

thread 'main' panicked at 'Out of order or duplicate change', tools\rls\src\actions\mod.rs:270:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[nrc]

@Diggsey what is the date of the nightly? And could you try again with today's (when its released). The Racer issue shouldn't crash the RLS, should just give sub-optimal code completion. The second error should be fixed. I hoped the third error should be fixed last week, but perhaps it is triggered by one of the previous crashes. In any case I'd be interested if it still happens, especially if it happens reliably (and I can get access to the project it's crashing for) - reproducing these crashes is the hardest part right now.

[kngwyu]

@Diggsey
About racer's bug, it's because racer tries to resolve dependencies manually by only Cargo.toml and Cargo.lock, without checking registry.
These kind of bugs are now fixed in my branch by kngwyu/racer-nightly#3, but I'm really not sure this will be merged into upstream.

[Diggsey]

@nrc what about the fourth error? That's happening for me pretty regularly right now.

thread 'main' panicked at 'Out of order or duplicate change', tools\rls\src\actions\mod.rs:270:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.

The problem is that it occurs when editing, not just from a particular project, but it happens all the time for me on any project.

[nrc]

I've been trying to investigate. I think what is happening is that the RLS is crashing for some other reason and then when it restarts, it's sequence numbers are out of sync with the editors, giving rise to the 'out of order' error.

[nrc]

This seems to be a bug either in the extension or VSCode - if the RLS crashes, and is then restarted, VS Code sends both the changes twice to the new RLS, crash again and we send the message three times, etc.

[nrc]

I just landed a fix on master which should cope with duplicate onChange notifications, though a better fix would be on the client side.