Repository navigation
assert desugaring change is backwards-incompatible #145770
Description
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);
}
Activity
lqd commentedon Aug 23, 2025
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 commentedon Aug 23, 2025
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 commentedon Aug 23, 2025
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 commentedon Aug 23, 2025
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 commentedon Aug 23, 2025
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 commentedon Aug 23, 2025
👌 Experiment
pr-145770created 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 commentedon Aug 25, 2025
(Regression run)
@craterbot name=pr-145770 p=1
craterbot commentedon Aug 25, 2025
📝 Configuration of the
pr-145770experiment changed.ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
14 remaining items
estebank commentedon Aug 26, 2025
Thankfully, it seems like they are all <=2021 edition, which would give us some latitude to land this in a way that new projects get the benefit. Sad that the lifetime issue wasn't resolved with the change I'd added to deal with it, though :-/
Amanieu commentedon Sep 10, 2025
@estebank Beta is branching later this week, if you are submitting a PR to revert it will need a beta backport.
estebank commentedon Sep 10, 2025
I won't be available to revert, I'm in transit. I won't be able to fix this before then. Feel free to revert the entire PR without me, I'm sorry :(
jieyouxu commentedon Sep 11, 2025
I opened a revert #146428 as I don't have bandwidth to investigate a limit-impact mitigation approach, and beta cutoff is close so.
Rollup merge of rust-lang#146428 - jieyouxu:revert-assert-desugaring,…
Unrolled build for #146428
theemathas commentedon Oct 25, 2025
Fixed by #146428