Complete removal of #[main] attribute from compiler

[jeremyBanks]

resolves#93786

---

The #[main] attribute was mostly removed from the language in #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).

#[main]fnmain(){println!("hello world");}

Aside from that oddity, the existence of this attribute causes code like the following to fail (playground link). According #84062 (comment), the removal of #[main] was expected to eliminate this conflict (previously reported as #62127).

use tokio::main;#[main]fnmain(){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, 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 #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.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

Please see the contribution instructions for more information.

[Mark-Simulacrum]

Cc @petrochenkov

[petrochenkov]

Looks like I just missed that main wasn't removed from the list of built-in attributes in #84217.
I'm going to mark this as beta nominated since it's a stable-to-stable regression.

[pnkfelix]

If I understand correctly, the main effect of this PR is to make code start erroring that is using the previously-built-in no-op #[main]. Any such code must inherently have that attribute by accident (since the attribute cannot be serving a purpose for any code that is using it).

I don't think I would beta backport this without at least a crater run, since we don't know how many crates out there might be using #[main] by accident.

It also looks like something that would be nearly trivial to put through a future-incompatibility warning cycle (which I know is essentially the opposite direction from a beta backport, but the nature of this problem seems like it deserves that treatment: i.e. its not an urgent matter to fix this).

The only argument I can see against a warning cycle is that its just extra tech debt hanging around in the compiler. Versus this PR, which immediately eliminates that tech debt. So this is sort of a microcosm of an ongoing prioritization question: should we prioritize the needs of an unknown but likely small set of Rust users over the needs of rustc contributors...

[petrochenkov]

I suggest backporting it sooner so it gets into the beta crater run, and reverting later if there are any regressions in non-nightly crates. If there's no time for that, then land it on nightly and wait for the next beta crater run.
What I suggest against is overthinking and spending more time on this.

[petrochenkov]

@bors r+ rollup

[bors]

📌 Commit 475e4ee has been approved by petrochenkov

[apiraino]

Beta backport accepted as per compiler team on Zulip

@rustbot label +beta-accepted