Skip to content

/rust

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

start / generated C main is the wrong type #20064

Closed
comex opened this Issue Dec 20, 2014 · 6 comments

Comments

Assignees
No one assigned
Labels
P-medium
Projects
None yet
Milestone
No milestone
7 participants
@comex @brson @tbu- @alexcrichton @pnkfelix @steveklabnik @thestinger
@comex
Copy link
Contributor

comex commented Dec 20, 2014

fn lang_start(main: *const u8, argc: int, argv: *const *const u8) -> int {

This is the signature both required for start fns and given to the C main wrapper function generated by create_entry_fn in librustc_trans/trans/base.rs. But it's clearly the wrong type: argc and the return value should be c_int or i32, not int.

@thestinger thestinger added I-wrong I-nominated labels Dec 20, 2014

@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Jan 8, 2015

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.

@huonw huonw referenced this issue Jan 14, 2015

Closed

`main` function has to implement wrong type. #21134

@tbu-

This comment has been minimized.

Sign in to view
Copy link
Contributor

tbu- commented Jan 14, 2015

If we have compiler glue anyway, argc should be usize.

I'm not so sure about the return type, i32 as default go-to integer might be fine here, I however don't see justification for isize.

@tbu- tbu- referenced this issue Jan 14, 2015

Closed

[r+] Intpocalypse, book edition. #21096

@brson brson added this to the 1.0 beta milestone Jan 15, 2015

@brson brson added the P-medium label Jan 15, 2015

@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Jan 15, 2015

Let's just gate it until we can think harder.

@brson brson assigned alexcrichton Jan 15, 2015

@alexcrichton alexcrichton removed the I-nominated label Jan 15, 2015

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 16, 2015

@alexcrichton
syntax: Feature gate #[start] and #[main] 
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
10a77b2

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 16, 2015

@alexcrichton
syntax: Feature gate #[start] and #[main] 
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
ccd1135

@alexcrichton alexcrichton referenced this issue Jan 16, 2015

Merged

syntax: Feature gate #[start] and #[main] #21257

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 16, 2015

@alexcrichton
syntax: Feature gate #[start] and #[main] 
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
38cb91e

bors added a commit that referenced this issue Jan 19, 2015

@bors
Auto merge of #21257 - alexcrichton:issue-20064, r=pnkfelix 
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
480c38f

bors added a commit that referenced this issue Jan 20, 2015

@bors
Auto merge of #21257 - alexcrichton:issue-20064, r=pnkfelix 
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
Loading status checks…
e375a89
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jan 20, 2015

Nominating for removal from milestone, this is now feature gated.

@alexcrichton alexcrichton added the I-nominated label Jan 20, 2015

@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Jan 22, 2015

Still P-high, but not 1.0 anymore since its gated.

@pnkfelix pnkfelix removed this from the 1.0 beta milestone Jan 22, 2015

@pnkfelix pnkfelix removed the I-nominated label Jan 22, 2015

@alexcrichton alexcrichton removed their assignment Apr 2, 2015

@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member

steveklabnik commented Jun 6, 2016

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.

@steveklabnik steveklabnik closed this Jun 6, 2016

@steveklabnik steveklabnik referenced this issue Jun 6, 2016

Open

Tracking issue for the `start` feature #29633

@dkl dkl referenced this issue Sep 28, 2017

Merged

Fix native main() signature on 64bit #44906

bors added a commit that referenced this issue Oct 1, 2017

@bors
Auto merge of #44906 - dkl:main-signature, r=nagisa 
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.
Loading status checks…
cfd9279

bors added a commit that referenced this issue Oct 1, 2017

@bors
Auto merge of #44906 - dkl:main-signature, r=nagisa 
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.
Loading status checks…
0defa20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.