-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
Is there a reason to do this other than cosmetic preference for another name? |
@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? |
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. |
The only place that comes close to this for me is osdev, and there, you use |
We still have |
@rfcbot reviewed |
@nrc I guess that is slightly different? I think that |
Ah yes, we've got three entry points. I.. think this is how they work:
So to answer your question, this isn't the same as |
🔔 This is now entering its final comment period, as per the review above. 🔔 psst @nikomatsakis, I wasn't able to add the |
The final comment period is now complete. |
We have no officially decided to REMOVE the Here are the steps to take:
These line numbers may drift over time. :/ For the records, I found them mostly by running UPDATE: #39282 is a good example of how to do a generic stabilization PR. |
I'd like to take this! |
@cramertj great! =) |
Something that's come up as I've been removing the feature that I don't see discussed here: the |
This is particularly useful when using |
Update on this, since it's been a while: I implemented the change, but it broke the test harness, which previously used the |
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. |
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. |
other whats? |
@nikomatsakis The entry points |
I see. I don't think any of them are stable, but not sure off the top of my head. |
Thanks. I suppose at least the lang item definitely wouldn't be. |
Triage: pretty sure that this is still where it was back in 2017. Since the previous issue was with test harness stuff, I wonder if and when custom test harnesses happen, it will alleviate this or not. |
I've been meaning to start more chats about revamping the test harness anyways to work with |
Just run into the issue preparing this playground. Looks like the compiler error E0601 is currently misleading, since it recommends the |
…henkov Complete removal of #[main] attribute from compiler resolves rust-lang#93786 --- The `#[main]` attribute was mostly removed from the language in rust-lang#84217, but not completely. It is still recognized as a builtin attribute by the compiler, but it has no effect. However, this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists), so it's possible to include it in code *on stable* without any errors, which seems unintentional. For example, the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!("hello world"); } ``` Aside from that oddity, the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According rust-lang#84062 (comment), the removal of `#[main]` was expected to eliminate this conflict (previously reported as rust-lang#62127). ```rust use tokio::main; #[main] fn main() { println!("hello world"); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114), as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional, and to needlessly block use of the `main` identifier in the attribute namespace, this PR finishes removing the `#[main]` attribute as described in rust-lang#29634 (comment) by deleting it from `builtin_attrs.rs`, and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.
…henkov Complete removal of #[main] attribute from compiler resolves rust-lang#93786 --- The `#[main]` attribute was mostly removed from the language in rust-lang#84217, but not completely. It is still recognized as a builtin attribute by the compiler, but it has no effect. However, this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists), so it's possible to include it in code *on stable* without any errors, which seems unintentional. For example, the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!("hello world"); } ``` Aside from that oddity, the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According rust-lang#84062 (comment), the removal of `#[main]` was expected to eliminate this conflict (previously reported as rust-lang#62127). ```rust use tokio::main; #[main] fn main() { println!("hello world"); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114), as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional, and to needlessly block use of the `main` identifier in the attribute namespace, this PR finishes removing the `#[main]` attribute as described in rust-lang#29634 (comment) by deleting it from `builtin_attrs.rs`, and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.
Tracks stabilzation of the
#[main]
attribute, which allows an arbitrary function to be tagged asmain
.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!
The text was updated successfully, but these errors were encountered: