rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
97.96k stars 12.69k forks source link

GAT: unconstrained lifetime in output when using GAT in fn type #77905

Open athre0z opened 4 years ago

athre0z commented 4 years ago
#![feature(generic_associated_types)]

trait Foo {
    type In<'a>;
}

struct Simple<'a>(std::marker::PhantomData<&'a u32>);

fn somefn_simple(f: for<'a> fn(Simple<'a>) -> Simple<'a>) {
    // compiles.
}

fn somefn_gat<T: Foo>(f: for<'a> fn(T::In<'a>) -> T::In<'a>) {
    // errors.
}

fn main() {}

I would expect somefn_gat to build just like somefn_simple does, however it currently results in this error:

warning: the feature `generic_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes
 --> src/main.rs:1:12
  |
1 | #![feature(generic_associated_types)]
  |            ^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(incomplete_features)]` on by default
  = note: see issue #44265 <https://github.com/rust-lang/rust/issues/44265> for more information

error[E0581]: return type references lifetime `'a`, which is not constrained by the fn input types
  --> src/main.rs:13:51
   |
13 | fn somefn_gat<T: Foo>(f: for<'a> fn(T::In<'a>) -> T::In<'a>) {
   |                                                   ^^^^^^^^^

error: aborting due to previous error; 1 warning emitted

For more information about this error, try `rustc --explain E0581`.
error: could not compile `playground`

To learn more, run the command again with --verbose.

rustc --version --verbose:

rustc 1.48.0-nightly (ef663a8a4 2020-09-30)

Click here for playground

b-naber commented 3 years ago

I don't think this is a bug. The following compiles:

#![feature(generic_associated_types)]

trait Foo {
    type In<'a>;
}

struct _Simple<'a>(std::marker::PhantomData<&'a u32>);

fn _somefn_simple(_f: for<'a> fn(_Simple<'a>) -> _Simple<'a>) {
    // compiles.
}

fn _somefn_gat<'a, T: Foo>(_f: for<'b> fn(T::In<'b>) -> T::In<'a>) {
    // errors.
}

fn main() {}
cynecx commented 3 years ago

@b-naber With your modifications 'a and 'b are possibly unrelated without extra outlives bounds. I think a better way to do this is?:

fn somefn_gat<'a, T: Foo>(f: fn(T::In<'a>) -> T::In<'a>) {
}
athre0z commented 3 years ago

Unfortunately, this code isn't equivalent. With your proposed variant, 'a needs to be defined by the call site. somefn_gat can't, for example, pass a reference to a local variable to f.

Comparing two playgrounds (without GAT, to not run into the issue described in the original post of this issue):

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=18e76ca1267c0d8f9ee00b1c30475d4c vs https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d3a835097a1f867242f7a3a75352d6f4

b-naber commented 3 years ago

I don't really understand how you want to call somefn_gat in your original example. How is the compiler supposed to infer T? You have to somewhere supply an instance that implements Foo or let somefn_gat be a trait method of Foo. Basically in your current example the function parameter has a type something like for<'a, T : Foo> fn(T::In<'a>) -> T::In<'a>, which as far as I know is not possible because the compiler uses monomorphization.

matthewjasper commented 3 years ago

This isn't specific to GATs.

trait Foo<'a> {
    type In;
}

struct Simple<'a>(std::marker::PhantomData<&'a u32>);

fn somefn_simple(f: for<'a> fn(Simple<'a>) -> Simple<'a>) {
    // compiles.
}

fn somefn_gat<T: for<'r> Foo<'r>>(f: for<'a> fn(<T as Foo<'a>>::In) -> <T as Foo<'a>>::In) {
    // errors.
}

fn main() {}

This is intended as <T as Foo<'a>>::In might be independent of 'a and so 'a cannot be inferred from the input type of the function. In this exact case this is fine because the output will also be independent of 'a in that case, but for something like for<'a> fn(<T as Foo<'a>>::In) -> &'a i32) would not be.

nikomatsakis commented 3 years ago

I agree this is not a bug. The error message could use work. The key point is that the lifetime 'a is not constrained by the function parameter types -- it is referenced, but not in the right way.