-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
regression: trait bound is not satisfied #123279
Comments
Regression in rust-lang-ci@e890bd9 searched nightlies: from nightly-2024-01-01 to nightly-2024-03-18 bisected with cargo-bisect-rustc v0.6.8Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start=2024-01-01 --end=2024-03-18 This PR definitely should not have changed behavior :/ |
I'll look into what's going on with it anyways -- it at least needs a MCVE @rustbot claim |
Implicitly reordering the pub trait Job: AsJob {
fn run_once(&self);
}
impl<F: Fn()> Job for F {
fn run_once(&self) {
todo!()
}
}
pub trait AsJob {
}
impl<T: Job + Sized> AsJob for T { // <----- changing this to `Sized + Job` or just `Job` will FIX it.
}
pub struct LoopingJobService {
job: Box<dyn Job>,
}
impl Job for LoopingJobService {
fn run_once(&self) {
self.job.run_once()
}
} I assume this is because of an overflow on the |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high |
… r=estebank Make sure to insert `Sized` bound first into clauses list rust-lang#120323 made it so that we don't insert an implicit `Sized` bound whenever we see an *explicit* `Sized` bound. However, since the code that inserts implicit sized bounds puts the bound as the *first* in the list, that means that it had the **side-effect** of possibly meaning we check `Sized` *after* checking other trait bounds. If those trait bounds result in ambiguity or overflow or something, it may change how we winnow candidates. (**edit: SEE** rust-lang#123303) This is likely the cause for the regression in rust-lang#123279 (comment), since the impl... ```rust impl<T: Job + Sized> AsJob for T { // <----- changing this to `Sized + Job` or just `Job` (which turns into `Sized + Job`) will FIX the issue. } ``` ...looks incredibly suspicious. Fixes [after beta-backport] rust-lang#123279. Alternative is to revert rust-lang#120323. I don't have a strong opinion about this, but think it may be nice to keep the diagnostic changes around.
… r=estebank Make sure to insert `Sized` bound first into clauses list rust-lang#120323 made it so that we don't insert an implicit `Sized` bound whenever we see an *explicit* `Sized` bound. However, since the code that inserts implicit sized bounds puts the bound as the *first* in the list, that means that it had the **side-effect** of possibly meaning we check `Sized` *after* checking other trait bounds. If those trait bounds result in ambiguity or overflow or something, it may change how we winnow candidates. (**edit: SEE** rust-lang#123303) This is likely the cause for the regression in rust-lang#123279 (comment), since the impl... ```rust impl<T: Job + Sized> AsJob for T { // <----- changing this to `Sized + Job` or just `Job` (which turns into `Sized + Job`) will FIX the issue. } ``` ...looks incredibly suspicious. Fixes [after beta-backport] rust-lang#123279. Alternative is to revert rust-lang#120323. I don't have a strong opinion about this, but think it may be nice to keep the diagnostic changes around.
Rollup merge of rust-lang#123302 - compiler-errors:sized-bound-first, r=estebank Make sure to insert `Sized` bound first into clauses list rust-lang#120323 made it so that we don't insert an implicit `Sized` bound whenever we see an *explicit* `Sized` bound. However, since the code that inserts implicit sized bounds puts the bound as the *first* in the list, that means that it had the **side-effect** of possibly meaning we check `Sized` *after* checking other trait bounds. If those trait bounds result in ambiguity or overflow or something, it may change how we winnow candidates. (**edit: SEE** rust-lang#123303) This is likely the cause for the regression in rust-lang#123279 (comment), since the impl... ```rust impl<T: Job + Sized> AsJob for T { // <----- changing this to `Sized + Job` or just `Job` (which turns into `Sized + Job`) will FIX the issue. } ``` ...looks incredibly suspicious. Fixes [after beta-backport] rust-lang#123279. Alternative is to revert rust-lang#120323. I don't have a strong opinion about this, but think it may be nice to keep the diagnostic changes around.
The text was updated successfully, but these errors were encountered: