Poor error for manual implementations of function traits

[jdm]

#![feature(fn_traits)]

struct S;

impl Fn(u32) -> u32 for S {
    fn call(&self) -> u32 {
        5
    }
}

fn main() {
}

This yields:

error[E0229]: associated type bindings are not allowed here
 --> foo2.rs:5:17
  |
5 | impl Fn(u32) -> u32 for S {
  |                 ^^^ associate type not allowed here

error: aborting due to previous error

Which is extremely confusing and non-actionable.

[jdm]

cc @jrmuizel

[durka]

It is sort of actionable if you know that Fn(u32) -> u32 really means Fn<(u32,), Output=u32>. Let's put that expansion in a note on the error message I guess?

[BGR360]

This code now produces two confusing errors:

#![feature(fn_traits)]
#![feature(unboxed_closures)]

struct S;

impl Fn(u32) -> u32 for S {
    fn call(&self) -> u32 {
        5
    }
}

fn main() {}

error[E0229]: associated type bindings are not allowed here
 --> src/main.rs:6:17
  |
6 | impl Fn(u32) -> u32 for S {
  |                 ^^^ associated type not allowed here

error[E0277]: expected a `FnMut<(u32,)>` closure, found `S`
  --> src/main.rs:6:6
   |
6  | impl Fn(u32) -> u32 for S {
   |      ^^^^^^^^^^^^^^ expected an `FnMut<(u32,)>` closure, found `S`
   |
   = help: the trait `FnMut<(u32,)>` is not implemented for `S`
note: required by a bound in `Fn`

In the first one, the erroneous span has moved inside of the parentheses, so I feel it's no longer as correct as it used to be, and no more helpful.

And the second one just seems... incorrect? Idk, I'm not intimately familiar with this nightly feature.

@rustbot label +D-confusing +D-terse +requires-nightly +D-incorrect

[estebank]

Current output:

error[E0229]: associated type bindings are not allowed here
 --> src/main.rs:8:17
  |
8 | impl Fn(u32) -> u32 for S {
  |                 ^^^ associated type not allowed here

[Ezrashaw]

My understanding of this issue is that the impl Fn(u32) -> u32 is expanded to impl Fn<(u32, ), Output = u32> where Output is not allowed and must be moved elsewhere.

Two issues currently seem to exist:

1. That the expansion (Fn(u32) -> u32 -> Fn<(u32, ), Output = u32>) for fn_traits is not shown. This can be addressed by adding a note to the error message.
2. That E0229 doesn't suggest a moving the associated type, this needs a proper suggestion and should be discussed more.

I'll work on 1. 2 seems out of scope of this issue.

@rustbot claim

[estebank]

@Ezrashaw if you're able to detect that you've got Fn trait syntax in the Trait part of the imp item, you should be able to print the type directly (to get the desugared version) and mention in passing "include type Output = u32 in the impl body instead" or something like that.

[Ezrashaw]

@estebank Isn't that suggestion generic to all "assoc type not allowed here" error?

[estebank]

Come to think of it, It would be.

[Ezrashaw]

Hmm, @estebank I think I've run into a problem: I cannot print the type. The error occurs is emitted from rustc_hir_analysis and so ype checking hasn't been done yet.

[estebank]

Because this is a nightly feature, I would side step the issue by not mentioning the type for now and only mention the "represent the closure with the regular trait syntax instead and move the output type to the body this way", but it should be easy to come up with a mechanism to translate from one syntax to the other (if it doesn't exist already!), while not having to rely on ty::*, only on the AST and resolve.