-
Notifications
You must be signed in to change notification settings - Fork 0
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
inductive cycles as ambig causes unintended breakage #114
Comments
original test by @aliemjay ❤️ pub trait ParallelIterator {
type Item;
}
impl<T> ParallelIterator for T {
type Item = u32;
}
trait Trait {}
impl<A, B> Trait for (A, B) where
//~^ type annotations needed: cannot satisfy `<<A as ParallelIterator>::Item as ParallelIterator>::Item == u32`
A: ParallelIterator,
A::Item: ParallelIterator<Item = u32>,
B: ParallelIterator,
B::Item: ParallelIterator<Item = u32>,
{}
fn main() {} |
This affects pub trait DimMin<D> {
type Output;
}
pub fn repro<R: DimMin<C>, C>()
where
<R as DimMin<C>>::Output: DimMin<C, Output = <R as DimMin<C>>::Output>,
{
} |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 13, 2025
solver cycles are coinductive once they have one coinductive step Implements the new cycle semantics in the new solver, dealing with the fallout from rust-lang/trait-system-refactor-initiative#10. I am currently also changing inductive cycles back to an error instead of ambiguity outside of coherence to deal with rust-lang/trait-system-refactor-initiative#114. This should allow nalgebra to compile without affecting anything on stable. Whether a cycle results in ambiguity or success should not matter for coherence, as it only checks for errors. The first commit has been extensively fuzzed via https://github.com/lcnr/search_graph_fuzz. TODO: - [ ] fix issues from https://hackmd.io/JsblAvk4R5y30niSNQVYeA - [ ] add ui tests - [ ] explain this approach and why we believe it to be correct r? `@compiler-errors` `@nikomatsakis`
also causes an ICE when normalizing for implied bounds fails:
trait I<'a, 'b, 'c> {
type As;
}
trait H<'d, 'e>: for<'f> I<'d, 'f, 'e> + 'd {}
struct X<'x, 'y> {
x: std::marker::PhantomData<&'x ()>,
y: std::marker::PhantomData<&'y ()>,
}
fn foo5<T>()
where
T: for<'l, 'i> H<'l, 'i, As: for<'j> H<'j, 'i, As: for<'k> H<'j, 'k, As = X<'j, 'k>> + 'j> + 'i>
{
}
fn main() {} |
also affects, in general this issue gets avoided by the old solver as its param_env normalization doesn't handle normalizeable aliases correctly
|
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Mar 10, 2025
…ompiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? `@compiler-errors` `@nikomatsakis`
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Mar 10, 2025
…ompiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? ``@compiler-errors`` ``@nikomatsakis``
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Mar 11, 2025
…ompiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? ```@compiler-errors``` ```@nikomatsakis```
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Mar 11, 2025
…ompiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? ````@compiler-errors```` ````@nikomatsakis````
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Mar 12, 2025
…ompiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? `````@compiler-errors````` `````@nikomatsakis`````
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Mar 12, 2025
…ompiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? ``````@compiler-errors`````` ``````@nikomatsakis``````
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 12, 2025
…ompiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? ```````@compiler-errors``````` ```````@nikomatsakis```````
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 12, 2025
Rollup merge of rust-lang#137314 - lcnr:cycles-with-unknown-kind, r=compiler-errors change definitely unproductive cycles to error builds on top of rust-lang#136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? ````````@compiler-errors```````` ````````@nikomatsakis````````
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Mar 14, 2025
…rrors change definitely unproductive cycles to error builds on top of #136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits. With this, we can change cycles which are definitely unproductive to a proper error. This fixes rust-lang/trait-system-refactor-initiative#114. This does not affect stable as we keep these cycles as ambiguous during coherence. r? ````````@compiler-errors```````` ````````@nikomatsakis````````
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
this should compile but fails with
The underlying issue is trying to prove
<A as Trait>::Item: Trait
normalizes the self type:normalizes-to(<A as Trait>::Item)
A::Item: Trait<Item = u32>
alias-relate(A::Item, A)
normalizes-to(<A as Trait>::Item)
inductive cycleB::Item: Trait<Item = i32>
alias-relate(B::Item, A)
normalizes-to(<B as Trait>::Item)
A::Item: Trait<Item = u32>
alias-relate(A::Item, B)
normalizes-to(<A as Trait>::Item)
inductive cycleB::Item: Trait<Item = i32>
alias-relate(B::Item, B)
normalizes-to(<B as Trait>::Item)
inductive cycleThe text was updated successfully, but these errors were encountered: