Allow "ABI agnostic" generics in FFI imports.

[eddyb]

For example, a C library might have the following API:

// All examples below assume these two types.
extern "C" {
    type Foo;
    type Bar;
}

extern "C" {
    fn foo_each_bar(
        foo: *mut Foo,
        callback_data: *mut c_void,
        callback: unsafe extern "C" fn(*mut c_void, *mut Bar),
    );
}

However, the c_void pointee makes it harder to use (having to cast to and from *mut c_void) and more error-prone (having no real type safety other than "it's a raw pointer and unsafe to deref").

We could, instead, allow this definition:

extern "C" {
    fn foo_each_bar<T>(
        foo: *mut Foo,
        callback_data: *mut T,
        callback: unsafe extern "C" fn(*mut T, *mut Bar),
    );
}

This is valid because we can fully compute the call ABI for foo_each_bar::<T> without knowing T (and this is something rustc has been able to do independently of LLVM for a while now).
If, e.g. <T> is replaced with <T: ?Sized>, the definition would be disallowed, since the layout of *mut T would then depend on the choice of T, as opposed to always being a pointer scalar.

If that last example works, we can also combine it with Rust references:

extern "C" {
    fn foo_each_bar<T>(
        foo: &Foo,
        callback_data: &mut T,
        callback: extern "C" fn(&mut T, &Bar),
    );
}

Note how the callback no longer needs to be unsafe (since it doesn't take raw pointers)!
An adapter for a closure being used as the callback can be as simple as:

extern "C" fn callback(f: &mut impl FnMut(&Bar), bar: &Bar) {
    f(bar);
}

(or even just |f, bar| f(bar) if we start coercing closures to non-Rust-ABI fn pointers)

cc @rust-lang/compiler

[strega-nil]

This seems like a good idea.

[rpjohnst]

I would love to have this sort of thing outside the context of FFI as well- a way to write generic code that's guaranteed not to be monomorphized because it's just passing around pointers.

[eddyb]

@rpjohnst That's a separate problem, rust-lang/rust#46477 (which should probably be renamed).
While FFI only cares about enforcing the call ABI doesn't depend on generic parameters, Rust functions with bodies need to have "parameter independence" found by analysis, and then codegen needs to be able to handle unsubstituted parameters (which would currently probably ICE a lot).

[comex]

(Saw this for the first time when I got an email notification due to it being transferred to the RFCs repo, so here's a reply to a year-old comment...)

@rpjohnst That's a separate problem, rust-lang/rust#46477 (which should probably be renamed).
While FFI only cares about enforcing the call ABI doesn't depend on generic parameters, Rust functions with bodies need to have "parameter independence" found by analysis, and then codegen needs to be able to handle unsubstituted parameters (which would currently probably ICE a lot).

I somewhat disagree. An optimization pass that discovers functions that happen to be "parameter independent" would be nice to have, but I'd also like a language feature to enforce independence at the source level. This would be useful as a way to control compile time and code size. And it would also allow such parameters to be object safe.

[eddyb]

@comex Fair, although that sounds a bit more like the fn foo<dyn T: Foo>(x: &T) {...} feature @nikomatsakis brings up sometimes (being able to refer to the type but trait dispatch being dynamic, a bit like Haskell/Java generics), which is a bit more involved.