1
Fork 0
rust/compiler/rustc_hir_analysis/src
bors ed43cbcb88 Auto merge of #134299 - RalfJung:remove-start, r=compiler-errors
remove support for the (unstable) #[start] attribute

As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.

I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*

`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is  a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.

Note that this feature has **not** been RFCed in the first place.

*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*

Closes https://github.com/rust-lang/rust/issues/29633

try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
2025-01-21 19:46:20 +00:00
..
check Auto merge of #134299 - RalfJung:remove-start, r=compiler-errors 2025-01-21 19:46:20 +00:00
coherence Normalize field before checking PhantomData in coerce/dispatch impl validation 2025-01-14 18:47:23 +00:00
collect Auto merge of #134504 - oli-obk:push-rltsvnyttwll, r=compiler-errors 2025-01-16 18:46:28 +00:00
errors Clarify implicit captures for RPITIT 2024-10-10 11:46:51 -07:00
hir_ty_lowering Rework trait expansion to happen once explicitly 2025-01-15 01:26:24 +00:00
impl_wf_check Fix const specialization 2024-12-02 22:21:53 +00:00
outlives Implement const effect predicate in new solver 2024-10-24 09:46:36 +00:00
variance Begin to implement type system layer of unsafe binders 2024-12-22 21:57:57 +00:00
autoderef.rs Arbitrary self types v2: use Receiver trait 2024-12-11 11:59:12 +00:00
bounds.rs Merge HostPolarity and BoundConstness 2024-10-30 16:23:16 +00:00
check_unused.rs Remove #[macro_use] extern crate tracing from rustc_hir_analysis. 2024-08-30 17:14:59 +10:00
collect.rs Add hir::HeaderSafety to make follow up commits simpler 2025-01-14 10:54:11 +00:00
constrained_generic_params.rs Remove #[macro_use] extern crate tracing from rustc_hir_analysis. 2024-08-30 17:14:59 +10:00
delegation.rs Effects cleanup 2024-10-26 10:19:07 +08:00
errors.rs remove support for the #[start] attribute 2025-01-21 06:59:15 -07:00
hir_wf_check.rs uplift fold_regions to rustc_type_ir 2024-11-28 10:40:58 +01:00
impl_wf_check.rs footnote to ordinary comment 2025-01-06 07:37:52 +01:00
lib.rs Do not project when there are unconstrained impl params 2025-01-03 05:01:14 +00:00