E0121 suggests the use of the unique type of a returned function/closure rather than a fn pointer or a Fn trait

[PatchMixolydic]

I tried this code:

fn f() -> i32 {
    0
}

fn returns_fn_pointer() -> _ {
    f
}

The resulting diagnostic suggests replacing _ with fn() -> i32 {f}, the unique type of f():

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> src/lib.rs:5:28
  |
5 | fn returns_fn_pointer() -> _ {
  |                            ^
  |                            |
  |                            not allowed in type signatures
  |                            help: replace with the correct return type: `fn() -> i32 {f}`

This, of course, doesn't work:

error: expected item, found `{`
 --> src/lib.rs:5:44
  |
5 | fn returns_fn_pointer() -> fn() -> i32 {f} {
  |                                            ^ expected item

I'd expect the diagnostic to suggest replacing _ with fn() -> i32 or impl Fn() -> i32, both of which compile successfully.

Meta

rustc --version --verbose:

rustc 1.50.0-nightly (2225ee1b6 2020-12-11)
binary: rustc
commit-hash: 2225ee1b62ff089917434aefd9b2bf509cfa087f
commit-date: 2020-12-11
host: x86_64-unknown-linux-gnu
release: 1.50.0-nightly

[PatchMixolydic]

@rustbot modify labels: +A-diagnostics +D-incorrect

[PatchMixolydic]

This also seems to happen with closures:

fn returns_closure() -> _ {
    || 5
}

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> src/lib.rs:1:25
  |
1 | fn returns_closure() -> _ {
  |                         ^
  |                         |
  |                         not allowed in type signatures
  |                         help: replace with the correct return type: `[closure@src/lib.rs:2:5: 2:9]`

[ThePuzzlemaker]

@rustbot claim

[ThePuzzlemaker]

Function pointers are now working, but it looks like closures will be a bit harder of a task.

fn f() -> i32 { 0 }
fn g() -> _ { f } 

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> <anon>:2:11
  |
2 | fn g() -> _ { f }
  |           ^
  |           |
  |           not allowed in type signatures
  |           help: replace with the correct return type: `fn() -> i32`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0121`.

[ThePuzzlemaker]

This brings up some questions though, unfortunately. For example, this code has the same type of issue:

fn f() -> i32 { 0 }
fn g() -> () { f }

This code brings up this diagnostic:

error[E0308]: mismatched types
 --> <anon>:2:16
  |
2 | fn g() -> () { f }
  |           --   ^ expected `()`, found fn item
  |           |
  |           expected `()` because of return type
  |
  = note: expected unit type `()`
               found fn item `fn() -> i32 {f}`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.

And to be honest, these diagnostics aren't entirely incorrect—that is the return type, it's just not valid syntax. Using a function pointer would be taking that unique type and coercing it into a function pointer or non-unique closure type.

Arguably, it should have something like help: this looks like a fn item, try using a function pointer: `fn() -> i32`, but doing this would end up meaning changing a lot of typeck code. I'm not really sure how to go through with this considering these things (as I'm not really too experienced with rustc code and therefore might mess up a bit of things).

[PatchMixolydic]

For errors like E0308, it would make sense to state the actual type since that is the root cause of the issue (functions cannot be coerced to ()). E0121, however, suggests replacing _ with the type it gives you, which falls apart in the face of these unnameable types. This can be a papercut to people who don't know how to return a function pointer/closure and become confused when the suggestion fails to compile.

This is probably problematic, since changing the Display impl of types (it seems like that's what's being used per rustc_typeck::collect::fn_sig) would likely mess up E0308 and other similar diagnostics.

I haven't looked into the underlying issue personally, but I can see a few options:

• Don't emit a suggestion for closures or functions. This is the simplest solution and would preserve the other typecheck-related diagnostics, but may be unhelpful to those who rely on E0121 as a simulacrum of typed holes.
• Add the fix to suggest using a fn pointer if the returned value is a function, but don't emit a suggestion for closures. I'm not sure of the depth of changes necessary for just this, and again, I'm not sure if this meshes well with other diagnostics.
• Emit a different suggestion for closures and possibly functions along the lines of consider using a Fn, FnOnce, or FnMut trait bound. For more information on Fn traits, see....

[ThePuzzlemaker]

I think that I'll probably do this I guess:

• If it's a function, suggest a function pointer, but also add that suggestion about a Fn/FnOnce/FnMut trait bound
• If it's a closure, suggest a Fn/FnOnce/FnMut trait bound as well

[ThePuzzlemaker]

Should I link to the Rust by Example on closure output types or maybe the std documentation for Fn?

[PatchMixolydic]

Rust by Example or The Book would probably be preferable since they explain Fn, FnMut, and FnOnce in one place, but I'm not certain if there's any precedent or policy about linking to them in diagnostics.

[ThePuzzlemaker]

Alright. Does this look good?
Function definition:

fn f() -> i32 { 0 }
fn g() -> _ { f }

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> <anon>:2:11
  |
2 | fn g() -> _ { f }
  |           ^
  |           |
  |           not allowed in type signatures
  |           help: replace with the correct return type: `fn() -> i32`
  |
  = help: also consider using a `Fn`, `FnMut`, or `FnOnce` trait bound
  = note: For more information on using `Fn` traits with function outputs, see https://doc.rust-lang.org/rust-by-example/fn/closures/output_parameters.html

error: aborting due to previous error

For more information about this error, try `rustc --explain E0121`.

I'll get closures in a bit, cause my rustc dev build decided to die on me and I have to completely rebuild it 🙁