Updating dependency caused type inference to fail on unrelated code

[sgrif]

Note: This is not a bug. This is a case that I ran into that was difficult to debug, and extremely confusing. In the interest of the ergonomics initiative, I wanted to report it. However, rustc is behaving as expected. Feel free to close this at your leisure.

At some point last night, Diesel's builds suddenly started failing for no apparent reason. This line was failing to infer that the _ there is bool (the Vec annotation is cruft from back when there needed to be a collect call as well). It was especially baffling, because the test above it is nearly identical, and this line was compiling just fine.

Eventually after cleaning up some build output and diffing it, we found that the only thing that had changed was a new version of serde_json being released. That led us to this commit, which made the reason for the failure much more obvious.

Nobody really did anything wrong here. Implementing a non-fundamental trait is defined as a minor breaking change in RFC #1105. However, the failure was extremely non-local and confusing. We were convinced this was a bug in rustc for a few hours until we finally tracked it down.

While there is no bug, I think two things could have improved this situation. First, I think we should consider amending that RFC so that implementing a trait which is not part of your crate for a type which is not part of your crate to be considered a major breaking change, as any code it breaks will be code which does not interact with that crate.

Secondly, I wonder if the error message could give some more diagnostic output here. If the message listed the impls of PartialEq for bool, this would have been immediately clear what had happened.

[killercup]

Pls add labels A-spooky-action-at-distance and I-takes-ages-to-track-down kthxbai

[Boscop]

I also ran into this, also involving serde_json! bluss is my witness. Very spooky indeed..

[wchargin]

Pls add labels A-spooky-action-at-distance and I-takes-ages-to-track-down kthxbai

I found this issue by searching for “action at a distance”, so thanks for adding this comment!

Believe it or not, I am also hitting this with serde_json. Hmm…

[kpreid]

I'm finding that assert_eq! can fail type inference “at a distance” without any traits or dependencies involved. Is this the same bug? I'd love to see something done about this because it creates error message clutter when I'm trying to locate real errors to fix. Repro code (stable 1.52.1):

fn troublesome() {
    does_not_exist();
}

fn innocent_bystander() {
    assert_eq!("x".as_bytes(), &[]);
}

error[E0425]: cannot find function `does_not_exist` in this scope
 --> src/lib.rs:2:5
  |
2 |     does_not_exist();
  |     ^^^^^^^^^^^^^^ not found in this scope

error[E0282]: type annotations needed
 --> src/lib.rs:6:5
  |
6 |     assert_eq!("x".as_bytes(), &[]);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
  |
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

If the error in troublesome is fixed, then the error in innocent_bystander also vanishes.