Type annotations needed in assertion

[laurmaedje]

Code

I tried this code:

fn main() {
    let array: [Box<i32>; 0] = [];
    assert_eq!(array.into_iter().collect::<Vec<_>>(), []);
}

I expected to see this happen: Compiles and assertion passes.

Instead, this happened: Compiler wants type annotation somewhere in assertion. Span is on whole assertion.

Version it worked on

It most recently worked on: 1.70 stable

Version with regression

Recent nightlies (also occurs on Rust playground)

rustc --version --verbose:

rustc 1.72.0-nightly (839e9a6e1 2023-07-02)
binary: rustc
commit-hash: 839e9a6e1210934fd24b15548b811a97c77138fc
commit-date: 2023-07-02
host: aarch64-apple-darwin
release: 1.72.0-nightly
LLVM version: 16.0.5

[lukas-code]

probaby caused by #112628

slightly smaller:

fn main() {
    let array: [Box<i32>; 0] = [];
    let _ = array == [];
}

error[[E0282]](https://doc.rust-lang.org/nightly/error_codes/E0282.html): type annotations needed
 --> src/main.rs:4:19
  |
4 |     let _ = array == [];
  |                   ^^ cannot infer type for type parameter `A2`

@rustbot label -regression-untriaged +regression-from-stable-to-nightly +T-libs

[lqd]

Almost no PRs in the #113105 rollup where it landed have artifacts, but it seems likely indeed. Especially when the PR itself has a comment about a similar regression #112628 (comment)

[lqd]

For visibility, cc PR author @gootorov, and reviewer @joshtriplett.

[tgross35]

I think our best case for now is to revert the commit and figure out what the fix is as time allows. I submitted a PR that adds a regression test and reverts: #113318

The invalid_type_param_default feature might be one way to fix this with a default type, but I'm not sure if this is anywhere near stable enough for indirect public use.

Vec has a similar PartialEq - can it be broken too?

[tgross35]

The Vec comparison has been stable for a year so I guess that one is fine ee23fd2. I'd still be curious to see a similar situation where Vec fails inference in a similar way, if it is possible.

[lukas-code]

I'd still be curious to see a similar situation where Vec fails inference in a similar way

If you just replace Box with Vec you also get an inference error:

fn main() {
    let array: [Vec<i32>; 0] = [];
    let _ = array == [];
}

error[[E0282]](https://doc.rust-lang.org/stable/error_codes/E0282.html): type annotations needed
 --> src/main.rs:3:22
  |
3 |     let _ = array == [];
  |                      ^^ cannot infer type

The reason why for type parameter `A2` doesn't show up in the error and ee23fd2 didn't regress inference is because Vec<T> as PartialEq<_> has always been ambiguous between PartialEq<&[T]>, PartialEq<&mut [T]>, and PartialEq<[T]>.

Box<T> as PartialEq<_> used to be unambiguous, inferring Box<T> as PartialEq<Box<T>>. With #112628, the more common case of Box<T> as PartialEq<Box<_>> is still unambiguous, but Box<T> as PartialEq<_> became ambiguous for the allocator of the right-hand side.

[Amanieu]

Closing since the revert has been merged.