Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # 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