start / generated C main is the wrong type #20064
Labels
P-medium
Medium priority
Comments
|
I'd prefer any lang items to use rust types and for the compiler or libs to generate any potentially platform-specific code necessary to glue things together. |
|
If we have compiler glue anyway, I'm not so sure about the return type, |
|
Let's just gate it until we can think harder. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jan 16, 2015
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc rust-lang#20064
bors
added a commit
that referenced
this issue
Jan 20, 2015
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc #20064
|
Nominating for removal from milestone, this is now feature gated. |
|
Still P-high, but not 1.0 anymore since its gated. |
|
This issue has been superceded by #29633, I will make note of this specific concern in that thread, since it does not seem to be mentioned there. |
bors
added a commit
that referenced
this issue
Oct 1, 2017
Fix native main() signature on 64bit Hello, in LLVM-IR produced by rustc on x86_64-linux-gnu, the native main() function had incorrect types for the function result and argc parameter: i64, while it should be i32 (really c_int). See also #20064, #29633. So I've attempted a fix here. I tested it by checking the LLVM IR produced with --target x86_64-unknown-linux-gnu and i686-unknown-linux-gnu. Also I tried running the tests (`./x.py test`), however I'm getting two failures with and without the patch, which I'm guessing is unrelated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
fn lang_start(main: *const u8, argc: int, argv: *const *const u8) -> int {This is the signature both required for
startfns and given to the C main wrapper function generated bycreate_entry_fninlibrustc_trans/trans/base.rs. But it's clearly the wrong type:argcand the return value should bec_intori32, notint.The text was updated successfully, but these errors were encountered: