Type inference breaks from a seemingly unrelated change

[kamulos]

I was just making changes in one of the crates in my workspace, when the code broke in another crate of the workspace. Rust is no longer able to infer the type automatically, with an explicit annotation it works again.

Feel free to close this bug report if this is to be expected, but to me this seems very unusual for Rust.

This is the code:

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct S {}

fn main() {
    // let s: S = serde_json::from_str("").unwrap();
}

fn check_len(len: &str) {
    let vec = vec![1, 2, 3];

    if vec.len() != len.parse().unwrap() {
        panic!();
    }
}

Uncomment the serde_json line to trigger the bug. After uncommenting Rust needs an explicit type annotation as usize for len.parse().

Meta

rustc --version --verbose:

rustc 1.65.0-nightly (c0941dfb5 2022-08-21)
binary: rustc
commit-hash: c0941dfb5a7d07ef2d70cc54d319669d9d6f6c01
commit-date: 2022-08-21
host: x86_64-unknown-linux-gnu
release: 1.65.0-nightly
LLVM version: 15.0.0

This occurs also with the stable and beta compiler

[5225225]

Right... This does seem to be intentional, but it's very not clear.

The issue is that you're doing usize != <some type>. Normally, the only other type that <some type> can be is usize, since you cannot compare a usize and anything else. So it's inferred to be usize, and everyone's happy.

But if you have serde_json being used (even just a use serde_json;), then that provides a usize != Value, so now it's possible that you could have meant "parse it into a serde_json Value".

The error message does tell you this to some extent:

error[E0283]: type annotations needed
  --> src/main.rs:13:25
   |
13 |     if vec.len() != len.parse().unwrap() {
   |                  --     ^^^^^ cannot infer type of the type parameter `F` declared on the associated function `parse`
   |                  |
   |                  type must be known at this point
   |
   = note: multiple `impl`s satisfying `usize: PartialEq<_>` found in the following crates: `core`, `serde_json`:
           - impl PartialEq for usize;
           - impl PartialEq<Value> for usize;
help: consider specifying the generic argument
   |
13 |     if vec.len() != len.parse::<F>().unwrap() {
   |                              +++++

For more information about this error, try `rustc --explain E0283`.

but I agree that the situation is confusing.

[kamulos]

OK thanks, I can see how this originated. And I certainly see how this is not changeable without breaking tons of code.

What seems unusual to me is how importing a crate breaks existing code. I think with the traits Rust goes to great length to avoid exactly this kind of situation. Wouldn't it be consistent for the compiler to say: "Please specify the type here, someone in the future might implement PartialEq for another type"?

Is there maybe a case where it is essential to infer the type automatically, if currently only one implementation exists?

[BGR360]

FYI here are other issues I know of that discuss this problem:

• Method resolution can be influenced in unexpected ways by external crates. #90907
• Cannot infer type for [], but only when serde_json is used (?) #89254
• Spurious E0282 'type annotations needed' when other compile errors exist #88630
• Updating dependency caused type inference to fail on unrelated code #44345

@rustbot label A-inference T-compiler

[Noratrieb]

Closing in favor of the other issues.