New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extern/native function reform #3678

Closed
nikomatsakis opened this Issue Oct 6, 2012 · 14 comments

Comments

Projects
None yet
8 participants
@nikomatsakis
Contributor

nikomatsakis commented Oct 6, 2012

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. (#3321)
  • Remove the current extern fn type (#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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 14, 2013

Contributor

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

Contributor

brson commented Feb 14, 2013

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

@asb

This comment has been minimized.

Show comment
Hide comment
@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 1, 2013

Contributor

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.

Contributor

brson commented Mar 1, 2013

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Mar 2, 2013

Contributor

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 :)
Contributor

nikomatsakis commented Mar 2, 2013

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 :)

bors added a commit that referenced this issue Mar 20, 2013

auto merge of #5445 : nikomatsakis/rust/issue-3678-refactor-trans_cal…
…l, r=graydon

Refactor trans_call to separate out the translation of the arguments, environment, and return pointer.  Towards #3678.  r? @brson

nikomatsakis added a commit to nikomatsakis/rust that referenced this issue Mar 25, 2013

Add AbiSet and integrate it into the AST.
I believe this patch incorporates all expected syntax changes from extern
function reform (rust-lang#3678). You can now write things like:

    extern "<abi>" fn foo(s: S) -> T { ... }
    extern "<abi>" mod { ... }
    extern "<abi>" fn(S) -> T

The ABI for foreign functions is taken from this syntax (rather than from an
annotation).  We support the full ABI specification I described on the mailing
list.  The correct ABI is chosen based on the target architecture.

Calls by pointer to C functions are not yet supported, and the Rust type of
crust fns is still *u8.
@brendanzab

This comment has been minimized.

Show comment
Hide comment
@brendanzab

brendanzab Jul 21, 2013

Member

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

Member

brendanzab commented Jul 21, 2013

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

@bstrie

This comment has been minimized.

Show comment
Hide comment
@bstrie

bstrie Aug 6, 2013

Contributor

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

Contributor

bstrie commented Aug 6, 2013

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

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Aug 15, 2013

Contributor

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.

Contributor

graydon commented Aug 15, 2013

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

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Aug 15, 2013

Contributor

accepted for backwards-compatible milestone

Contributor

graydon commented Aug 15, 2013

accepted for backwards-compatible milestone

@nwoeanhinnogaehr

This comment has been minimized.

Show comment
Hide comment
@nwoeanhinnogaehr

nwoeanhinnogaehr Feb 13, 2015

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

nwoeanhinnogaehr commented Feb 13, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment