Should externfn! include an abi?

[erickt]

It's now recommended to use externfn!(...) to bind to a C library function, but those external functions are being declared with the implicit Rust abi. For example, this script errors out:

externfn!(fn foo())
//extern "C" { fn foo(); }

fn bar(_f: extern "C" unsafe fn()) { }

fn main() {
    bar(foo)
}

It errors with:

foo.rs:8:8: 8:11 error: mismatched types: expected `extern "C" unsafe fn()` but found `extern "Rust" unsafe fn()` (expected "C" fn but found "Rust" fn)
foo.rs:8     bar(foo)
                 ^~~
error: aborting due to previous error

Swapping the comments gets it to compile fine. Is this safe? Given that #10052 says the Rust ABI is not precisely defined as the C ABI, should we change externfn! to include an ABI argument to future proof our bindings?

[nikomatsakis]

I'm not really opposed to this, but I'm not sure I'd say it's "recommended" to use externfn!. The role of externfn! is to bridge from extern to Rust (though I guess it could be generalized to "bridge from ABI to ABI"). However, if we opt to remove segmented stacks, we wouldn't need externfn! at all (it's not clear to me we need it now...)

[erickt]

@nikomatsakis: I figured it was recommended because of the tutorial-ffi document. It talks about how externfn! can save some of the tedium of writing ffi functions. It doesn't mention that externfn! does not specify the ABI.

[nikomatsakis]

Likely a non-issue, since we are removing segmented stacks and thus (hopefully) the need for externfn!