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

Tracking issue for `main` feature #29634

Open
aturon opened this Issue Nov 5, 2015 · 22 comments

Comments

Projects
None yet
@aturon
Member

aturon commented Nov 5, 2015

Tracks stabilzation of the #[main] attribute, which allows an arbitrary function to be tagged as main.

Status Update

Decision was reached to remove this feature and looking for someone to implement; here is a list of instructions, feel free to reach out to @nikomatsakis for more tips!

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Dec 18, 2015

Is there a reason to do this other than cosmetic preference for another name?

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Nov 11, 2016

@rfcbot fcp close

I propose that we just remove this feature altogether. I don't see a lot of clamoring for it. =) There are three users according to @brson's survey though -- @brson, was that just a grep that cratesio or what?

@rfcbot

This comment has been minimized.

rfcbot commented Nov 11, 2016

Team member @nikomatsakis has proposed to close this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@steveklabnik

This comment has been minimized.

Member

steveklabnik commented Nov 11, 2016

The only place that comes close to this for me is osdev, and there, you use no_main rather than main, so...

@nrc

This comment has been minimized.

Member

nrc commented Nov 13, 2016

We still have start or whatever for doing this do we?

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Nov 13, 2016

@rfcbot reviewed

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Nov 14, 2016

@nrc I guess that is slightly different? I think that #[start] configures at a higher-level than main? Perhaps @alexcrichton or @brson can expound on that.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Nov 14, 2016

Ah yes, we've got three entry points. I.. think this is how they work:

  • First, #[start], the receiver of int argc and char **argv. This is literally the symbol main (or what is called by that symbol generated in the compiler).
  • Next, there's #[lang = "start"]. If no #[start] exists in the crate graph then the compiler generates a main function that calls this. This functions receives argc/argv along with a third argument that is a function pointer to the #[main] function (defined below). Importantly, #[lang = "start"] can be located in a library. For example it's located in the standard library (libstd).
  • Finally, #[main], the main function for an executable. This is passed no arguments and is called by #[lang = "start"] (if it decides to). The standard library uses this to initialize itself and then call the Rust program. This, if not specified, defaults to fn main at the top.

So to answer your question, this isn't the same as #[start]. To answer your other (possibly not yet asked) question, yes we have too many entry points.

@rfcbot

This comment has been minimized.

rfcbot commented Dec 21, 2016

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @nikomatsakis, I wasn't able to add the final-comment-period label, please do so.

@rfcbot

This comment has been minimized.

rfcbot commented Jan 23, 2017

The final comment period is now complete.

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Jan 24, 2017

We have no officially decided to REMOVE the #[main] feature and would welcome any help from someone who wishes to do it!

Here are the steps to take:

  • remove the feature from the list src/libsyntax/feature_gate.rs:136 and add it to the list of removed features found around line 316
  • the attribute main should be removed from the list in BUILTIN_ATTRIBUTES at src/libsyntax/feature_gate.rs:443;
  • the code in src/librustc/middle/entry.rs:89 (and mirrored code in src/libsyntax/entry.rs:29) should be adjusted to remove the case covering else if attr::contains_name(&item.attrs, "main") {
  • the feature gate code from src/libsyntax/feature_gate.rs:1056 can be removed
  • presumably the code in and around src/libsyntax/test.rs:206 that references "main" can be removed too
  • write a test trying to use the feature and show that it errors out

These line numbers may drift over time. :/ For the records, I found them mostly by running ripgrep '"main"' =)

UPDATE: #39282 is a good example of how to do a generic stabilization PR.

@nikomatsakis nikomatsakis added the E-easy label Jan 25, 2017

@cramertj

This comment has been minimized.

Member

cramertj commented Jan 27, 2017

I'd like to take this!

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Jan 27, 2017

@cramertj great! =)

@cramertj

This comment has been minimized.

Member

cramertj commented Jan 28, 2017

Something that's come up as I've been removing the feature that I don't see discussed here: the #[main] attribute allows you to specify main functions that aren't defined at crate-level. I'm not sure how useful/idiomatic this is, but it is used in the existing test harness and a couple other places.

@cramertj

This comment has been minimized.

Member

cramertj commented Jan 28, 2017

This is particularly useful when using #[cfg(...)]'d modules like in this intrinsic-alignment test.

@cramertj

This comment has been minimized.

Member

cramertj commented Feb 14, 2017

Update on this, since it's been a while: I implemented the change, but it broke the test harness, which previously used the #[main] attribute in order to override the program's existing main fn. I explored a few other options, such as replacing/renaming the existing main function with the test harness, but it was pretty unwieldy. As I mentioned to @nikomatsakis over email, I think the best way forward is to either keep the #[main] feature around for internal use only (the easiest solution, but leaves the codebase cluttered with obsolete features), or to implement the test harness using #[start] (which, if I understand correctly, requires manually running some sort of initialization for std). What do you all think?

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Mar 14, 2017

I'm removing the E-easy / E-mentor tags. Based on @cramertj's experience, I don't actually know what's the best way forward at the moment, so i wouldn't consider this easy.

@Ericson2314

This comment has been minimized.

Contributor

Ericson2314 commented May 8, 2017

Sorry to hijack a bit, but are any of the others currently stable? I'd like to get a definitive list of what would benefit from a general solution to the "needs provides" problem.

Oh and thanks for the list @alexcrichton. I don't recall all three described side-by-side elsewhere so that was handy.

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented May 8, 2017

@Ericson2314

are any of the others currently stable?

other whats?

@cramertj

This comment has been minimized.

Member

cramertj commented May 8, 2017

@nikomatsakis The entry points #[start], #[lang = "start"], and #[main]. I think @Ericson2314 was referencing this comment.

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented May 11, 2017

I see. I don't think any of them are stable, but not sure off the top of my head.

@Ericson2314

This comment has been minimized.

Contributor

Ericson2314 commented May 11, 2017

Thanks. I suppose at least the lang item definitely wouldn't be.

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