assert desugaring change is backwards-incompatible

[cramertj]

This code compiles on stable, but is broken after #122661. This is causing a breakage in the bitvec crate.

#[derive(Debug)]
struct F {
    data: bool
}

impl std::ops::Not for F {
  type Output = bool;
  fn not(self) -> Self::Output { !self.data }
}

fn main() {
  let f = F { data: true };

  assert!(f);
}

See discussion on the PR.

[lqd]

This breakage wasn’t seen in the crater results due to https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/crater.3A.20.3E100k.20.22prepare-fail.22.20crates.3F

[Skgland]

This breakage wasn’t seen in the crater results due to https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/crater.3A.20.3E100k.20.22prepare-fail.22.20crates.3F

I could have made it more clearer that prepare-fail is a spurious failure and in contrast to error is included in the retry-regressed-list.txt making it easier to retry. But I wouldn't see my comment nor the introduction of the prepare-fail category as the reason for this issue.

Rather the problem is that crater doesn't point out the amount of crates on the retry-regessed-list.txt resulting in these indeterminate results being overlooked and no retry being performed. In this regard I opened rust-lang/crater#791 suggesting to include that number in the crater bot comment on crater run completion to raise awareness.

[lqd]

To be clear the issue we need to fix is why so many crates are failing with space issues. Changing how these errors are categorized will help by making this more visible for sure; people would retry their runs with the spurious regressions until the space issue is fixed. The root cause is the latter, not your categorization improvements.

[estebank]

For now, let's just revert and I'll try to figure out another strategy. Worse case scenario, we gate it on the next edition, however much that saddens me. That being said, let's do that after the beta crater runs, as I'd like to get a better sense of what the actual fallout was.

[compiler-errors]

That being said, let's do that after the beta crater runs

We don't need to wait until beta crater runs, though, which would be beta 1.91 afaict.

We should just be able to re-run crater on the affected crates list (which includes the prepare-fail crates). If it's the case that the affected crates are not spurious, then they'd fail in the beta crater run too and thus also be ignored, so we're really not gaining much by waiting.

I'm gonna start the crater run here since the other PR has like 200 comments so it's kinda hard to navigate.

@craterbot check crates=https://crater-reports.s3.amazonaws.com/pr-122661-1/retry-regressed-list.txt start=master#82310651b93a594a3fd69015e1562186a080d94c end=try#a2a6e871b05c7b8ecc9a3c8a20db1f39e995e399

[craterbot]

👌 Experiment pr-145770 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[jieyouxu]

(Regression run)
@craterbot name=pr-145770 p=1

[craterbot]

📝 Configuration of the pr-145770 experiment changed.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more