Skip to content
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

non-defining opaque type use: bogus "generic lifetime used twice" #115013

Closed
aliemjay opened this issue Aug 20, 2023 · 2 comments · Fixed by #117371
Closed

non-defining opaque type use: bogus "generic lifetime used twice" #115013

aliemjay opened this issue Aug 20, 2023 · 2 comments · Fixed by #117371
Labels
C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@aliemjay
Copy link
Member

I expect this to compile:

#![feature(type_alias_impl_trait)]
type Opaque<'lt> = impl Sized + 'lt;
fn test<'a>(
    arg: impl Iterator<Item = &'a u8>,
) -> impl Iterator<Item = Opaque<'a>> {
    arg
}

Instead, it is an error in 1.73.0-nightly (2023-08-16 07438b0):

error: non-defining opaque type use in defining scope
 --> src/lib.rs:5:6
  |
5 | ) -> impl Iterator<Item = Opaque<'a>> {
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ generic argument `'a` used twice
  |
note: for this opaque type
 --> src/lib.rs:5:6
  |
5 | ) -> impl Iterator<Item = Opaque<'a>> {
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: item constrains opaque type that is not in its signature
 --> src/lib.rs:5:6
  |
5 | ) -> impl Iterator<Item = Opaque<'a>> {
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this item must mention the opaque type in its signature in order to be able to register hidden types
note: this item must mention the opaque type in its signature in order to be able to register hidden types
 --> src/lib.rs:3:4
  |
3 | fn test<'a>(
  |    ^^^^
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Aug 20, 2023
@aliemjay aliemjay added C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Aug 20, 2023
@compiler-errors
Copy link
Member

First error should be fixed by ignoring the bivariant RPIT params. The second error should go away if we fix the first one.

@wenym1
Copy link

wenym1 commented Aug 29, 2023

From my practice, the rust compiler has problem in nested impl Trait with lifetime. In the code above, the code is similar to impl Iterator<impl Sized>, which is a nested impl Trait.

We can try the following way to avoid nested-ly deducing the concrete type of impl Trait.

#![feature(type_alias_impl_trait)]

type Opaque<'lt> = impl Sized + 'lt;
fn test<'a>(
    arg: impl Iterator<Item = &'a u8>,
) -> impl Iterator<Item = Opaque<'a>> {
    arg.map(identity)
}

fn identity<'a>(input: &'a u8) -> Opaque<'a> {
    input
}

The basic idea is to deduce the concrete type of Opaque in a separate function, so that the compiler would not have to deduce the two nested impl Trait in the same place.

@bors bors closed this as completed in 12eb539 Oct 30, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 30, 2023
Rollup merge of rust-lang#117371 - compiler-errors:unique-params, r=oli-obk

Ignore RPIT duplicated lifetimes in `opaque_types_defined_by`

An RPIT's or TAIT's own generics are kinda useless -- so just ignore them. For TAITs, they will always be empty, and for RPITs, they're always duplicated lifetimes.

Fixes rust-lang#115013.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants