Sean Stangl wrote:
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.
Good point. We can't actually remove the ABI from the Rust source altogether, as we can't generate code without knowing the precise ABI, but I can see that in some cases you would want to set the ABI as a kind of configuration setting and not specified within the source. One easy way to achieve this would be with a macro or #[cfg] settings (e.g., `cfunc!(a, b -> c)` could generate `extern "aapcs" fn(a, b) -> c` and so forth). This seems like an interesting intersection with the designs for Rust's package system. Another way would be to allow ABI settings that are configuration variables (`extern c! fn(...)`) or something. Truth be told, though, however we do it probably doesn't impact me too much because I imagine that kind of think would be substituted away in front-end pass :)
Also—a slight amendment to what I wrote earlier, I imagine the best rules would be to permit one cross-platform specification (C, Rust) to be combined with per-platform specifications, so that you can say "use the default on most platforms, but on ARM use (whatever)".
Niko _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
