Implement Debug, Pointer, etc on function pointers for all calling conventions

[Kampfkarren]

Extends the default function pointer implementations, such as Debug, to all stable calling conventions.

I would like to extend this to the unstable calling conventions as well, but cannot find a way to do so that appeases ineffective_unstable_trait_impl.

[rust-highfive]

r? @yaahc

(rust-highfive has picked a reviewer for you, use r? to override)

[dtolnay]

@rustbot author

[Kampfkarren]

Going to be completely out next week--will try to finish up reviews the week after, apologies.

[Kampfkarren]

Will finish tomorrow, promise, apologies

[Kampfkarren]

CC @yaahc

[yaahc]

@rustbot ready

[yaahc]

r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs

[dtolnay]

The changes look good so far, but I don't think this can be merged as currently implemented without further work in rustdoc. This PR changes doc/core/primitive.fn.html from 1.4 MB to 14 MB which is beyond what is reasonable and getting into crashy territory for browsers.

@Kampfkarren could you please look into making rustdoc render all these repetitive impls in some more compact way?

[RalfJung]

This overlaps with #96513.

[RalfJung]

The changes look good so far, but I don't think this can be merged as currently implemented without further work in rustdoc. This PR changes doc/core/primitive.fn.html from 1.4 MB to 14 MB which is beyond what is reasonable and getting into crashy territory for browsers.

Another potential concern is the size of the rlib. How much bugger does compiled libcore become through all these extra instances?

[lcnr]

As an alternative solution we could (and should imo) add a builtin trait:

trait FnPtr {
    // Alternatively `-> usize` idc
    fn as_ptr(self) -> *const ();
    // Other additions, like `const VARIADIC: bool` or whatever can be added if needed
}

This trait can then be used to implement Debug, Pointer and so on for all function pointers at once. I think even the existing number of impls in https://doc.rust-lang.org/nightly/std/primitive.fn.html is already far from ideal. I would generally be available to mentor/push that effort.

[RalfJung]

// Alternatively -> usize idc

Cc #95489 -- I am not sure which option is more portable, but #97420 seems to prefer usize.

[CAD97]

[trait FnPtr] can then be used to implement Debug, Pointer and so on for all function pointers at once.

If this is done via a blanket impl<F: FnPtr> Debug for F, doing so will require a coherence-impacting #[sealed] (or hacking that onto FnPtr directly) to avoid prohibiting downstream impls of the traits IIUC.

[lcnr]

the coherence implications should fall out directly from the compiler internal impl of trait FnPtr. I don't expect there to be any issues here.

[dtolnay]

Another potential concern is the size of the rlib. How much bigger does compiled libcore become through all these extra instances?

On my machine, comparing 764b861...8efec95, this PR increases the size of libcore.rlib from 57834522 bytes to 71612866 bytes, or 23.8%.

[Kampfkarren]

Hm. Any way around that?

[RalfJung]

Yes, it was proposed here 15 days ago. That will help a lot. But as others noted above it might need some new trait system trickery.

Even better would be to make FnPtr a magic trait that is automatically implemented for all fn types.

[bors]

☔ The latest upstream changes (presumably #98180) made this pull request unmergeable. Please resolve the merge conflicts.

[Kampfkarren]

I don't think I have the time to make a more closer to the compiler change like an FnPtr trait right now (and it feels like I'd want to have an RFC for that anyway)

[RalfJung]

FWIW a FnPtr trait could start as a library-only change: using a macro to implement FnPtr for a lot of fn types. That would still lead to a smaller rmeta file than the current approach, since we only have 1 instance per fn type, not N (one for each relevant trait).

[CAD97]

Related:

• Improve the function pointer docs #98180 does this (as in the collapsing multiple into one) for the docs.