1.90.0 regression: type inference fails when comparing `CString` array with empty array literal

[magicant]

Code

I tried this code:

fn main() {
    let v: [std::ffi::CString; 0] = [];
    assert_eq!(v, []);
}

I expected to see this happen: successful build.

Instead, this happened:

$ cargo +stable r
   Compiling e0282 v0.1.0 (/home/magicant/Projects/e0282)
error[E0282]: type annotations needed
 --> src/main.rs:3:5
  |
3 |     assert_eq!(v, []);
  |     ^^^^^^^^^^^^^^^^^ cannot infer type
  |
  = note: this error originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0282`.
error: could not compile `e0282` (bin "e0282") due to 1 previous error

Version it worked on

It most recently worked on: 1.89.0

Version with regression

rustc --version --verbose:

rustc 1.90.0 (1159e78c4 2025-09-14)
binary: rustc
commit-hash: 1159e78c4747b02ef996e55082b704c09b970588
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.90.0
LLVM version: 20.1.8

Backtrace

None. (No crash)

Additional notes

This might be related to the new PartialEq impls for CStr(ing) that were stabilized in 1.90.0.

[theemathas]

Presumably caused by #137268
cc @bjoernager

[theemathas]

The crater run did not detect yash's regression, as both yash-builtin-0.7.0 and yash-env-0.7.0 produced the following error in crater:

this task or one of its parent failed: No space left on device (os error 28)

The crater run had a high number of errors (152539 of them). Maybe this needs a crater rerun?

[theemathas]

Ah, a crater rerun was already done in #143164.

[theemathas]

Although..... the crater rerun had a large number of prepare-fail results (167516 of them). Maybe a second rerun is needed?

[bjoernager]

Behaviour using CString is now equivalent to how using String and/or OsString has been since rustc 1.0.0. What exactly is the problem?

[workingjubilee]

@bjoernager This affects type inference by changing what is a viable candidate for this comparison. This is always a hazard when adding more PartialEq candidates.

[magicant]

I'm personally fine with adding type annotations on my side.
I created this issue because I was not sure whether this incompatibility was intentional or an oversight.

[workingjubilee]

Yes, type inference is one of those things we don't promise works exactly the same, even on the algorithm level, so this is always a permitted breakage, in a sense. We usually try to avoid having it impact common cases, but our tooling for doing so is imperfect.

[Amanieu]

This change was intentional, as per this comment: #143164 (comment)