Type inference regression on Nightly

[antonok-edm]

Code

This minimized code example:

fn main() -> Result<(), &'static str> {
    let a = 0usize;
    let b = &a;

    let _c: usize = {
        let d = &""
            .parse()
            .map_err(|_| "")?;
        b + d
    };

    Ok(())
}

should compile successfully.

Instead, I get the following 2 compiler errors:

error[E0277]: cannot add `&()` to `&usize`
 --> src/main.rs:9:11
  |
9 |         b + d
  |           ^ no implementation for `&usize + &()`
  |
  = help: the trait `Add<&()>` is not implemented for `&usize`

error[E0277]: the trait bound `(): FromStr` is not satisfied
    --> src/main.rs:7:14
     |
7    |             .parse()
     |              ^^^^^ the trait `FromStr` is not implemented for `()`
     |
note: required by a bound in `core::str::<impl str>::parse`
    --> /home/antonok/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/str/mod.rs:2247:21
     |
2247 |     pub fn parse<F: FromStr>(&self) -> Result<F, F::Err> {
     |                     ^^^^^^^ required by this bound in `core::str::<impl str>::parse`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `regression` due to 2 previous errors

Version it worked on

It most recently worked on: Rust 1.57.0 (beta)

Version with regression

rustc --version --verbose:

rustc 1.59.0-nightly (db9d361a4 2021-11-28)
binary: rustc
commit-hash: db9d361a4731ca0bb48533fab6297a8fea75696f
commit-date: 2021-11-28
host: x86_64-unknown-linux-gnu
release: 1.59.0-nightly
LLVM version: 13.0.0

Backtrace

N/A

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

[inquisitivecrystal]

Well, that's interesting. This regression appears to stem from #89167. CC @workingjubilee.

I'd guess the type inference has become ambiguous due to library changes, which is ordinarily allowed. It might be worth improving the error message somehow though.

[antonok-edm]

Bizarre 😄

I assume it must also be related to #90904 then.

[inquisitivecrystal]

@antonok-edm: we should probably close this in favor of #90904. Do you want to post your code sample there? It's shorter and easier to parse than the one that's there now.

[antonok-edm]

@inquisitivecrystal sure, that makes sense!