Rust: Spurious attempt to load a crate resulting in "multiple rlib candidates for `debug_unreachable` found".

[eddyb]

I've reduced a triggering example to this:

use a::A;
type B<'a, T> = C<&'a T>;

Producing (on playground, in Rust 2018 mode, only on nightly):

error[E0465]: multiple rlib candidates for `debug_unreachable` found
  |
note: candidate #1: /playground/target/debug/deps/libdebug_unreachable-dc2ba43f474707f3.rlib
note: candidate #2: /playground/target/debug/deps/libdebug_unreachable-fedb7fe62f71c3f0.rlib

The names in the testcase appear to not matter, but I can't figure out why both a lifetime and a type parameter need to be present, or any of the other details.

My guess this is from the rustc_resolve speculative loading of crates, to give better suggestions, which I must've not made foolproof (I thought I made all the errors lazy, but maybe this from a different spot that I missed).

cc @petrochenkov

[petrochenkov]

Crate loading is certainly not fully speculative, at leas with regards to non-existent paths (https://github.com/rust-lang/rust/issues/55103), so it's possible that some other errors are also reported eagerly.

[Arnavion]

This appears to be fixed in nightly, but the original issue is now in beta.

---

Edit: Actually, using the non-existent import does still trigger the bug on nightly.

use a::A;
struct S {
    a: A,
}

playground

[shepmaster]

And stable 1.31.1

[ghost]

_nightly release_ still has this, but _nightly debug_ does not! (I hope it's not because I ran debug first and release later)
(also _stable debug_ and _beta debug_ still have this, but it might be because I ran their release before their debug? So, did release create one rlib and debug the second? Is that why the error is on the debug then?)

I hit it with my example too (playground):

#[derive(Debug)]
struct A(i32);

fn main() {
    let mut v = vec![A(1), A(2)];

    //let first = &v[0];

    v.push(A(6));
    //let first = &v[0]; //all errors go away if I uncomment this, even the "multiple rlib" one


    println!("The first element is: {:?}", first);
}

EDIT: New example(tested on rust nightly debug):

fn main() {
    for _ in 1..1 {}
}

fn change(i: &mut NewType) {}

(I can't trigger any of these(or OP) examples locally with a rustc that's 1 day older than the nightly in playground - so I'm assuming it only happens in playground, or simply cargo build and cargo build --release aren't enough to trigger this locally)

[ghost]

Question: Does this explain it? ie. is it actually a cargo bug?

ok, it's probably just that which was already mentioned above.

[shepmaster]

Stable (1.33.0), Beta (1.34.0-beta1), and Nightly (1.35.0-nightly 2019-03-14 bc44841ad2a2ad5f6c5e) all continue to experience this problem.

Here's an example that reproduces the problem:

[package]
name = "repro"
version = "0.1.0"
edition = "2018"

[dependencies]
debug_unreachable = "0.1.1"
new_debug_unreachable = "1.0.3"

use std::rc::Rc;

struct Wat(Rc<Derp>);

fn main() {
  let mut b: [i32; 10] = Default::default();
}

   Compiling repro v0.1.0 (/private/tmp/r)
error[E0465]: multiple rlib candidates for `debug_unreachable` found
  |
note: candidate #1: /private/tmp/r/target/debug/deps/libdebug_unreachable-9846113be7cd0a2b.rlib
note: candidate #2: /private/tmp/r/target/debug/deps/libdebug_unreachable-843675cb387b3fdc.rlib

error[E0412]: cannot find type `Derp` in this scope
 --> src/main.rs:3:15
  |
3 | struct Wat(Rc<Derp>);
  |               ^^^^ not found in this scope

Of interest is that edition = "2018" is required to trigger the error

[jethrogb]

This is now on stable, but it appears fixed on nightly

[shepmaster]

but it appears fixed on nightly.

My code example continues to have the error in nightly on the playground.

[lqd]

The code example in https://github.com/rust-lang/rust/issues/56590#issuecomment-450535106 still fails on nightly as well, but in Release mode only, while some examples from other comments fail in Debug only, and finally there are also examples (such as Shep's) failing in both Debug and Release.

[garrettmaring]

Is there a known workaround for this? I am still seeing this issue with 1.44.0-nightly.

[petrochenkov]

Fixed in https://github.com/rust-lang/rust/pull/74071.