objc2 fails to build on latets nightly

[kchibisov]

Our CI in winit started breaking on nightly recently due to inability of recent rustc nightly to build the https://github.com/madsmtm/objc2 crate, in particular you can look into madsmtm/objc2#432 issue.

Error

The error we get is:

 error[E0277]: `<<I as IvarType>::Type as InnerIvarType>::Output` is not an iterator
   --> /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.3.0-beta.3.patch-leaks.2/src/declare/ivar_forwarding_impls.rs:165:5
    |
165 |     fn nth(&mut self, n: usize) -> Option<<<Self as Deref>::Target as Iterator>::Item> {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `<<I as IvarType>::Type as InnerIvarType>::Output` is not an iterator
    |
    = help: the trait `Iterator` is not implemented for `<<I as IvarType>::Type as InnerIvarType>::Output`
note: required for `ivar::Ivar<I>` to implement `Iterator`
   --> /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.3.0-beta.3.patch-leaks.2/src/declare/ivar_forwarding_impls.rs:154:19
    |
154 | impl<I: IvarType> Iterator for Ivar<I>
    |                   ^^^^^^^^     ^^^^^^^
155 | where
156 |     <Self as Deref>::Target: Iterator,
    |                              -------- unsatisfied trait bound introduced here
help: consider further restricting the associated type
    |
165 |     fn nth(&mut self, n: usize) -> Option<<<Self as Deref>::Target as Iterator>::Item> where <<I as IvarType>::Type as InnerIvarType>::Output: Iterator {
    |                                                                                        ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

error[E0277]: `<<I as IvarType>::Type as InnerIvarType>::Output` is not an iterator
   --> /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-0.3.0-beta.3.patch-leaks.2/src/declare/ivar_forwarding_impls.rs:165:5
    |
165 |     fn nth(&mut self, n: usize) -> Option<<<Self as Deref>::Target as Iterator>::Item> {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `<<I as IvarType>::Type as InnerIvarType>::Output` is not an iterator
    |
    = help: the trait `Iterator` is not implemented for `<<I as IvarType>::Type as InnerIvarType>::Output`
help: consider further restricting the associated type
    |
165 |     fn nth(&mut self, n: usize) -> Option<<<Self as Deref>::Target as Iterator>::Item> where <<I as IvarType>::Type as InnerIvarType>::Output: Iterator {
    |                                                                                        ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I expected to see this happen: it should build.

Instead, this happened: it doesn't build, see above.

Version it worked on

It most recently worked on: rust version 1.69.0-nightly (31f858d 2023-02-28)

Version with regression

rustc --version --verbose:

rust version 1.70.0-nightly (da7c50c08 2023-03-19)

[madsmtm]

Note in particular that it's only the overridden fn nth (which we override simply because Box does) that fails to build, and only with a bit of a complicated trait bound.

A smaller reproducer can be found in this playground.

If you either remove the fn nth implementation, or change the <Self as Deref>::Target with the type it refers to, <I::Type as InnerIvarType>::Output, the example now builds.

[lukas-code]

searched nightlies: from nightly-2023-03-18 to nightly-2023-03-26
regressed nightly: nightly-2023-03-20
searched commit range: 4a04d08...da7c50c
regressed commit: 8826b68

bisected with cargo-bisect-rustc v0.6.5

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc -- check 

Regression in #104100.

Looks like this is caused by this bound:

rust/library/core/src/iter/traits/iterator.rs

Line 393 in 89c2e3d

Self::Item: ~const Destruct,

@rustbot label -E-needs-bisection

[madsmtm]

That's what I suspected, thanks for confirming it!

Though I agree with the assessment in madsmtm/objc2#432 (comment) that the added ~const Destruct bound should not cause issues, though perhaps the combination of the bound and a bug in the trait solver causes the issue?

[fee1-dead]

It's not supposed to regress normal code, but if it does it is a bug. I'm going to look into this when I have time.

[lukas-code]

This seems to be a general limitation of the old trait solver and unrelated to Destruct specifically.

But it works with the new trait solver (RUSTFLAGS=-Ztrait-solver=next), so maybe we should just hold back on const iterators until the new trait solver becomes stable.

demo

pub struct GenericType<T>(T);

pub trait Trait1 {
    type Assoc1;
}

trait Trait2 {
    type Assoc2;
}

impl<T: Trait1> Trait2 for GenericType<T> {
    type Assoc2 = T::Assoc1;
}

trait Anything {}

trait MyIterator {
    type MyItem;
    fn my_nth() where Self::MyItem: Anything;
}

impl<T: Trait1> MyIterator for GenericType<T>
where
    <Self as Trait2>::Assoc2: MyIterator,
    // <T as Trait1>::Assoc1: MyIterator, // stop-gap fix
{
    type MyItem = <<Self as Trait2>::Assoc2 as MyIterator>::MyItem;
    fn my_nth() {}
}

Compiling playground v0.0.1 (/playground)
error[E0277]: the trait bound `<T as Trait1>::Assoc1: MyIterator` is not satisfied
  --> src/lib.rs:28:5
   |
28 |     fn my_nth() {}
   |     ^^^^^^^^^^^ the trait `MyIterator` is not implemented for `<T as Trait1>::Assoc1`
   |
note: required for `GenericType<T>` to implement `MyIterator`
  --> src/lib.rs:22:17
   |
22 | impl<T: Trait1> MyIterator for GenericType<T>
   |                 ^^^^^^^^^^     ^^^^^^^^^^^^^^
23 | where
24 |     <Self as Trait2>::Assoc2: MyIterator,
   |                               ---------- unsatisfied trait bound introduced here
help: consider further restricting the associated type
   |
28 |     fn my_nth() where <T as Trait1>::Assoc1: MyIterator {}
   |                 +++++++++++++++++++++++++++++++++++++++

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` due to previous error

(also the suggestion is wrong)

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high +T-compiler