Tracking Issue for `FnStatic` and `FnPtr::addr`/`from_ptr`/`as_ptr` and `Code`

[programmerjake]

Feature gate: #![feature(fn_static)]

This is a tracking issue for FnStatic and FnPtr::addr/from_ptr/as_ptr and Code.

Public API

// core::ops

pub extern type Code;

// Implemented only for function pointers.
pub unsafe trait FnPtr {
    fn addr(self) -> usize;
    fn as_ptr(self) -> NonNull<Code>;
    unsafe fn from_ptr(NonNull<Code>) -> Self;
}

// Implemented for all types that coerce to function pointers.
pub unsafe trait FnStatic<Args>: Fn<Args> {
    type FnPtr: FnPtr;
    fn as_fn() -> Self::FnPtr;
    fn addr() -> usize;
    fn as_ptr() -> NonNull<Code>;
    extern "rust-call" fn call_static(args: Args) -> Self::Output;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: API for explicitly getting an opaque pointer of a function libs-team#589
• t-lang approval because FnStatic is a new builtin trait that interacts with the language, as well as discussing how to deal with new targets where code pointers are bigger than data pointers.
• Implementation: #...
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Is it sufficient to just add type aliases whenever adding a target where code pointers are bigger than data pointers? It was proposed that NonNull<Code> is used for pointing to the code of a function, and that whenever a target where code pointers are larger than data pointers is added, then type aliases are added and APIs are changed to use those type aliases instead of directly using NonNull<Code> or usize when representing code addresses.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[programmerjake]

@rustbot label +T-lang +I-lang-nominated

[programmerjake]

for reference, some examples of targets we might add where code pointers are bigger than data pointers: rust-lang/libs-team#589 (comment)