Printed function definition types can be confusing

[glandium]

I tried this code:

use curl_sys::{curl_easy_setopt, CURLOPT_READFUNCTION};
use libc;

// (...)
curl_easy_setopt(curl, CURLOPT_READFUNCTION, libc::fread);

I expected to see this happen: maybe not a failure, or a failure that is not completely confusing.

Instead, this happened:

error[E0617]: can't pass `unsafe extern "C" fn(*mut core::ffi::c_void, usize, usize, *mut libc::unix::FILE) -> usize {libc::unix::fread}` to variadic function
   --> hg_connect.rs:844:62
    |
844 |                 curl_easy_setopt(curl, CURLOPT_READFUNCTION, libc::fread);
    |                                                              ^^^^^^^^^^^
    |
help: cast the value to `unsafe extern "C" fn(*mut core::ffi::c_void, usize, usize, *mut libc::unix::FILE) -> usize`
    |
844 |                 curl_easy_setopt(curl, CURLOPT_READFUNCTION, libc::fread as unsafe extern "C" fn(*mut core::ffi::c_void, usize, usize, *mut libc::unix::FILE) -> usize);
    |                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note how it suggests to cast to the exact same type it started with.

rustc --version --verbose:

rustc 1.43.0-nightly (5e7af4669 2020-02-16)
binary: rustc
commit-hash: 5e7af4669f80e5f682141f050193ab679afdb4b1
commit-date: 2020-02-16
host: aarch64-unknown-linux-gnu
release: 1.43.0-nightly
LLVM version: 9.0

[jonas-schievink]

That's not the same type, it just prints "fn item" in a very similar way to "fn pointer". The former is zero-sized, while the latter is pointer-sized.

[glandium]

Are you saying that the {libc::unix::fread} part is supposed to indicate that?

[jonas-schievink]

Yeah, it indicates that it's the type of that specific fn item, and not an fn pointer.

[glandium]

That... is really not obvious.

[Centril]

I agree it isn't; but on the other hand I'm not sure what would be clear without also taking up a lot of space... ideas?

cc @estebank

[estebank]

An option would be to move the function name after the fn instead of after the signature, but doubt that would be enough. Best bet would be to add extra wording to the message about this being a specific function and expecting a function pointer, but the wording of those two is too close and lends itself to the same confusion we have now. Because of that, I think we should add a note explaining the nuance for these cases.

[jumbatm]

How about something like this?

error[E0617]: can't pass `{individual function type for libc::unix::fread}` to variadic function
   --> hg_connect.rs:844:62
    |
844 |                 curl_easy_setopt(curl, CURLOPT_READFUNCTION, libc::fread);
    |                                                              ^^^^^^^^^^^
    |
help: cast the value to a function pointer:
    |
844 |                 curl_easy_setopt(curl, CURLOPT_READFUNCTION, libc::fread as unsafe extern "C" fn(*mut core::ffi::c_void, usize, usize, *mut libc::unix::FILE) -> usize);
    |                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'd argue that confusion comes from seeing the "same" function signature so many times, so it's vital to distinguish between the individual function type vs the function pointer type as much (and as obviously) as possible.

[HTGAzureX1212]

@rustbot release-assignment

[HTGAzureX1212]

@rustbot assign

[rustbot]

Error: Parsing assign command in comment failed: ...'bot assign' | error: specify user to assign to at >| ''...

Please let @rust-lang/release know if you're having trouble with this bot.

[HTGAzureX1212]

@rustbot claim