Extern/native function reform

[nikomatsakis]

Per some meeting or other, we discussed a plan to reform how how C functions work. I have been laying some of the groundwork for this but I think there is no meta-bug discussing it and bringing together the various things that need to be done.

The plan is:

• Add a type extern "abi" fn(S) -> T where abi is one of the Rust-supported ABIs, and defaults to C. (Add extern "abi" fn type to represent C pointers #3321)
• Remove the current extern fn type (Remove bare function types, replace with inference #3320) and extern fn (crust fn) declarations
  • Allow bare fns to be inferred to extern fn type; in trans, we generate a wrapper at that time
• Remove the wrappers in trans that we currently use to adapt C functions to Rust ABI
  • When calling a function of extern fn type, we will generate inline the C-abi style invocation, perhaps generating wrappers

[brson]

There have been more recent discussions on this topic: https://mail.mozilla.org/pipermail/rust-dev/2013-January/003013.html

[asb]

Plus a blog post: http://smallcultfollowing.com/babysteps/blog/2013/02/22/interfacing-with-c-functions-in-rust/

[brson]

Completing the crust function change likely requires implementing #4479 - when making the foreign call we need to set up the stack pointer correctly so that, when foreign code calls the crust function, it can resume calculating stack boundaries correctly.

[nikomatsakis]

Some notes on the plan of attack:

[22:19:20] <nmatsakis> so it seems to me that we can:
[22:19:38] <nmatsakis> (1) implement a prepare_extern_call which is a no-op
[22:19:41] <nmatsakis> (2) implement the lint mode
[22:19:51] <nmatsakis> (3) insert the calls to prepare_extern_call
[22:20:02] <nmatsakis> (4) change prepare_extern_call to do the stack switch and change the call itself to do nothing
[22:20:23] <nmatsakis> -- or rather, remove the wrappers etc
[22:20:37] <nmatsakis> (5) change prepare_extern_call to just reserve a chunk of memory
[22:20:49] <nmatsakis> (6) have a beer
[22:20:59] <nmatsakis> by which I mean: implement a painful and annoying deriving mode
[22:21:03] <nmatsakis> does that sound about right?
[22:23:05] <brson> about, but you may hit problems with those reentrant crust functions between 4 & 5 when prepare_extern_call tries to switch stacks again
[22:23:28] <nmatsakis> right, so prepare_extern_call should reproduce the current smart behavior
[22:23:30] <nmatsakis> in its first iteration
[22:24:10] <brson> that behavior probably depends in some way on the assumption that crust functions do a stack switch, which will no longer be true, so it may just need to change
[22:24:32] <brson> or it may just work :)
[22:26:33] <nmatsakis> ok, this sounds like a plan.
[22:26:39] <nmatsakis> we'll see how it goes :)

[brendanzab]

Any word on this? It is very important for getting us some great OpenGL bindings.

[bstrie]

Echoing @bjz's question. I don't even see this in the bors queue anymore.

[graydon]

visiting for triage. apparently any day now. Properly classified, nominating for back-compat or possibly well-defined. Though I imagine it'll land before we've got it accepted/rejected.

[graydon]

accepted for backwards-compatible milestone

[nwoeanhinnogaehr]

It appears that this isn't complete yet: linking to foreign functions with a "Rust" or "RustCall" ABI is not implemented. See here.