Skip to content
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

#[main] attribute was unintentionally stabilized (as no-op) in 1.53.0 #93786

Closed
jeremyBanks opened this issue Feb 8, 2022 · 1 comment · Fixed by #93753
Closed

#[main] attribute was unintentionally stabilized (as no-op) in 1.53.0 #93786

jeremyBanks opened this issue Feb 8, 2022 · 1 comment · Fixed by #93753
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jeremyBanks
Copy link
Contributor

jeremyBanks commented Feb 8, 2022

Code

I tried this code:

#[main]
fn main() {}

I expected an error, because the main attribute has never been available on stable, and had apparently been removed in #84217.

Instead, the program ran without error, although the attribute has no apparent effect.

Version it worked on

It most recently worked as expected (emitting an error) on Rust 1.52.1:

$ cargo +1.52.1 build    
   Compiling regression-testing v0.0.0 (/Users/jeremy/src/github.com/jeremyBanks/rust-regression)
error[E0658]: declaration of a non-standard `#[main]` function may change over time, for now a top-level `fn main()` is required
 --> src/main.rs:2:1
  |
2 | fn main() {}
  | ^^^^^^^^^^^^
  |
  = note: see issue #29634 <https://github.com/rust-lang/rust/issues/29634> for more information

Version with regression

This stopped being an error in 1.53.0 (in which a warning was still emitted), and continues to be accepted in stable through the current 1.58.1 version (in which the warning has also disappeared).

$ cargo +1.53.0 build    
   Compiling regression-testing v0.0.0 (/Users/jeremy/src/github.com/jeremyBanks/rust-regression)
warning: unused attribute
 --> src/main.rs:1:1
  |
1 | #[main]
  | ^^^^^^^
  |
  = note: `#[warn(unused_attributes)]` on by default
$ cargo +1.58.1 build    
   Compiling regression-testing v0.0.0 (/Users/jeremy/src/github.com/jeremyBanks/rust-regression)
@jeremyBanks jeremyBanks added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Feb 8, 2022
@rustbot rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed regression-untriaged Untriaged performance or correctness regression. labels Feb 8, 2022
@jeremyBanks jeremyBanks changed the title #[main] attribute was accidentally stabilized (as no-op) in 1.53.0 #[main] attribute was unintentionally stabilized (as no-op) in 1.53.0 Feb 9, 2022
@apiraino
Copy link
Contributor

apiraino commented Feb 9, 2022

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high +T-compiler

@rustbot rustbot added P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Feb 9, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 9, 2022
…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`.
@bors bors closed this as completed in 84c2804 Feb 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants