Cross-crate RPITIT loses bounds

[Ltrlg]

Cross-crate

I tried this code:

a/src/lib.rs

#![feature(return_position_impl_trait_in_trait)]

pub trait A {
    fn get_iter(&self) -> impl Iterator<Item = ()>;
}

b/src/lib.rs

use a::A;

pub fn b(a: &impl A) -> usize {
    a.get_iter().count()
}

Compiled fine with 1.72.0-nightly (5ea666864 2023-06-27), but gives the following error with 1.72.0-nightly (5bd28f5ea 2023-06-28):

error[E0599]: `impl ?Sized` is not an iterator
 --> src/lib.rs:6:18
  |
4 |     a.get_iter().count()
  |                  ^^^^^ `impl ?Sized` is not an iterator
  |
  = note: the following trait bounds were not satisfied:
          `impl ?Sized: Iterator`
          which is required by `&mut impl ?Sized: Iterator`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `b` (lib) due to previous error

Single crate

My initial attempt at minimizing the case shown that the single-crate equivalent:

c/src/lib.rs

#![feature(return_position_impl_trait_in_trait)]

pub trait A {
    fn get_iter(&self) -> impl Iterator<Item = ()>;
}

pub fn b(a: &impl A) -> usize {
    a.get_iter().count()
}

compiles just fine.

Meta

rustc --version --verbose:

rustc 1.72.0-nightly (5bd28f5ea 2023-06-28)
binary: rustc
commit-hash: 5bd28f5eac1ba3569bfa8d49ec3f5acbdfdff7a0
commit-date: 2023-06-28
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

EDIT: Reduced reproduction code.

[lqd]

(This is a #![feature(return_position_impl_trait_in_trait)] issue that is fixed under -Zlower-impl-trait-in-trait-to-assoc-ty and #112988).

cc @spastorino: a nice test case to add.

[compiler-errors]

@lqd: Why do you think this is a limitation of the current lowering? This should definitely work with the current lowering and ideally shouldn't be dependent on -Zlower-impl-trait-in-trait-to-assoc-ty. This is just a plain bug 🤣

@rustbot claim

[lqd]

The reason: incorrect eyeballing + complete ignorance of the subject matter, AKA saying stupid things 😅 .

Even better it it's fixable without requiring the new lowering.

[compiler-errors]

This regressed in #98867, cc @cjgillot. I will fix this, but I hope that PR doesn't also regress other things, like the last time the encoding for certain items was reduced without sufficient tests :/