Closed chris-morgan closed 2 years ago
searched nightlies: from nightly-2021-10-17 to nightly-2021-11-28 regressed nightly: nightly-2021-10-26 searched commit range: https://github.com/rust-lang/rust/compare/00d5e42e776da900049fe19087bc9b0057ec70cd...29b1248025b19bd132c8047fc710ea9314b9b76b regressed commit: https://github.com/rust-lang/rust/commit/41d8c94d454f23239715a6433df79e46df8bce04
Bisection points to #89427. There were some changes to when the compiler avoids emitting an ambiguity error when there are previous errors, but I'm not sure what the intent was. The appearance of ambiguity errors similar to this one was noted in PR review.
@rustbot label regression-from-stable-to-stable
@rustbot claim
cc @estebank
FWIW, using 1.58.1 I accidentally ran into the same regression (undesirable / surplus E0283) with the following defective code:
trait SomeInteger { fn bleep(&self); }
impl SomeInteger for i8 { fn bleep(&self) {} }
impl SomeInteger for i32 { fn bleep(&self) {} }
fn bleep_it(a: Box<dyn SomeInteger>) {
a.bleep();
}
fn main() {
let number_of_yaks = 3;
bleep_it(Box::new(number_of_yaks));
print!("we have run out of {yaks} to shave");
}
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.
@rustbot label -I-prioritize +P-medium
@compiler-errors I'm pretty sure this is caused by this removal:
I would rather us not add it in the same place because IIRC I moved it (duplicated) deeper into the logic because otherwise with my other changes we had regressions.
I was just going through my FizzBuzz article as I do every year or so to update compiler error messages and make any related changes necessary, and came across a regression in error output for Figure 3.
Given the following code:
This is the output in 1.57.0 (and it’s been just the one error that we now call E0308 right from the outset):
But the output in 1.58.0 and in currently nightly adds another error, E0283:
The integer type inference error is spurious, because if you resolve the if/else type mismatch (e.g. tack on
.to_string()
on the other branches), it also vanishes (resolved to the default of i32, I presume).