assertion error: c.num == crate_map.len() as u32

[nikomatsakis]

I am using the RLS, setup in emacs. I get this error:

thread '<unnamed>' panicked at 'assertion failed: c.num == crate_map.len() as u32', /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/rls-analysis-0.11.0/src/lowering.rs:125:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', libcore/result.rs:945:5

when running on the mathema repository (e.g., this commit)

I don't know how best to reproduce otherwise -- I can try running in VSCode, but I don't have that setup.

[nikomatsakis]

When I try in VLS, I just get "RLS: working" seemingly forever. Not sure if there's a way to see more detail.

[nikomatsakis]

I tried rm -rf target and restarting emacs. Got same error.

[nrc]

I can repro and the problem is with the mathema crate when it is referencing Serde. I think it is a combination of how rustc is handling the new extern crate-less crate imports and the Serde crate being pulled in by a macro maybe? The dep crate nums are 1-20 and then 46. So this seems like an invariant in rustc has changed, not sure whether that is a bug or whether we should work around this in rls-analysis.

[nikomatsakis]

@nrc ah of course I totally forgot that I am using new features :)

[nrc]

I fixed the direct cause of this by dropping the assumption that crate numbers are sequential. We no longer get this bug, but we get an even weirder one, in:

impl MathemaOptions {
    crate fn directory(&self) -> Fallible<PathBuf> {
        Ok(match &self.directory {
            Some(s) => Path::new(s).to_owned(),
            None => env::current_dir()?,
        })
    }
}

The definition of s has a crate number of 21, which is not a valid crate number. Since it is a local variable, I would expect it to have a crate number of 0, I don't see how it can have any other crate number. I suppose we have gone wrong somewhere in emitting or processing the save-analysis data.

[nrc]

Sigh, I was way off-base with the above. The problem seems to be an import:

use extern::{structopt::StructOpt, structopt_derive::StructOpt};

(specifically the first StructOpt, but I suspect they'd all have the same problem)

The crate number for structopt is 11 but that is not a crate which is listed in the save-analysis prelude list of crates.

[nrc]

rust-lang/rust#48742 Is the Rust issue for the missing crate thing. I'll need some guideance from compiler folk to solve that. I have a solution to non-sequential crate numbers, but it might be unnecessary if they are only non-sequential because of the missing crates.

[sinkuu]

rust-lang/rust#48742 is fixed.

[nrc]

Thanks for the fix @sinkuu !