Specifying ABI on the rust side may not be desirable. For example, ARM contains the option of at least the ABIs "armeabi"/"gnueabi" and "armeabi-v7"/"gnueabi-v7". This might be OK if Rust never intends to support cross-compilation, but with a number of targets, explicit annotations would get very hairy for no real gain.
But on top of that, a single ARM system may use disjoint ABIs in terms of softfp/hardfp, so autodetection wouldn't be valid since either is a valid option but the decision is significant. It might be better for Rust to just express "this uses some C calling convention", and then have the specific convention decided at configuration time by the person compiling. Sean ----- Original Message ----- From: "Patrick Walton" <[email protected]> To: [email protected] Sent: Wednesday, March 13, 2013 10:20:42 AM Subject: Re: [rust-dev] ABI Opinion Poll On 3/13/13 9:16 AM, Niko Matsakis wrote: > One simple improvement would be having the compiler issue an error if > you either: > > 1. Combine a cross-platform ABI with any single-platform ABIs > 2. Specify multiple single-platform ABIs that apply to the same platform. > > That's very easy. > > Oh, and two function types are only compatible if the ABI set is identical. I guess it would be possible to use subtyping here so that e.g. `extern "aapcs cdecl" fn` is a subtype of `extern "cdecl" fn`, but that sounds like overkill. Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
