remove support for the (unstable) #[start] attribute #134299

RalfJung · 2024-12-14T08:31:50Z

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 and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.

Closes #29633

try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various

rustbot · 2024-12-14T08:31:59Z

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2024-12-14T09:18:26Z

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

src/tools/tidy/src/ui_tests.rs

tests/ui/runtime/running-with-no-runtime.rs

RalfJung · 2024-12-14T11:37:15Z

@Noratrieb

Those arguments are just stubbed out to zero on Windows, for example.

Given that we have several tests that inspect these arguments and that apparently pass on Windows, this cannot be entirely true.

ChrisDenton · 2024-12-14T11:54:20Z

Given that we have several tests that inspect these arguments and that apparently pass on Windows, this cannot be entirely true.

There is a difference here between #[lang = "start"] and #[start]. The former we use zeros, the latter we grab them from the C main function.

Noratrieb · 2024-12-14T11:56:39Z

The start stuff is very confusing, it's possible I got that wrong yeah. Removing #[start] makes it simpler :)

RalfJung · 2024-12-14T12:16:39Z

There is a difference here between #[lang = "start"] and #[start]. The former we use zeros, the latter we grab them from the C main function.

Where is this implemented?

ChrisDenton · 2024-12-14T12:18:55Z

rust/compiler/rustc_codegen_ssa/src/base.rs

Line 534 in ed14192

    
           fn get_argc_argv<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>(bx: &mut Bx) -> (Bx::Value, Bx::Value) {

RalfJung · 2024-12-14T12:20:27Z

tests/codegen/mainsubprogramstart.rs

We still have codegen/mainsubprogram.rs which tests that this works for regular binaries.

RalfJung · 2024-12-14T12:22:00Z

rust/compiler/rustc_codegen_ssa/src/base.rs

Line 534 in ed14192

fn get_argc_argv<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>(bx: &mut Bx) -> (Bx::Value, Bx::Value) {

That function acts depending on target.main_needs_argc_argv, not depending on whether we use #[start] or the start lang item. So this doesn't seem to match what you said earlier?

main_needs_argc_argv is set by default for most targets. The exception are some headless ARM targets and wasm targets.

ChrisDenton · 2024-12-14T12:40:29Z

Huh, you're right. I'm 99% sure we used to but maybe that was a long time ago.

bors · 2025-01-21T14:07:36Z

⌛ Trying commit 56c90dc with merge 8aa896a...

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](rust-lang#29633 (comment)) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.* Closes rust-lang#29633 try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various

bors · 2025-01-21T16:40:03Z

☀️ Try build successful - checks-actions
Build commit: 8aa896a (8aa896a894e6d1b037d5933a8c5331cd6a75219d)

RalfJung · 2025-01-21T16:52:59Z

@bors r=compiler-errors

bors · 2025-01-21T16:53:02Z

📌 Commit 56c90dc has been approved by compiler-errors

It is now in the queue for this repository.

bors · 2025-01-21T19:46:24Z

⌛ Testing commit 56c90dc with merge ed43cbc...

rust-highfive · 2025-01-21T22:26:23Z

📣 Toolstate changed by #134299!

Tested on commit ed43cbc.
Direct link to PR: #134299

💔 nomicon on windows: test-pass → test-fail (cc @Gankra @JohnTitor @frewsxcv).
💔 nomicon on linux: test-pass → test-fail (cc @Gankra @JohnTitor @frewsxcv).

@Gankra

Tested on commit rust-lang/rust@ed43cbc. Direct link to PR: <rust-lang/rust#134299> 💔 nomicon on windows: test-pass → test-fail (cc @Gankra @JohnTitor @frewsxcv). 💔 nomicon on linux: test-pass → test-fail (cc @Gankra @JohnTitor @frewsxcv).

bors · 2025-01-21T22:27:29Z

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing ed43cbc to master...

rust-timer · 2025-01-21T23:44:52Z

Finished benchmarking commit (ed43cbc): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.4%, -0.2%]	4
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.0%, secondary 4.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.7%, 1.3%]	2
Regressions ❌ (secondary)	4.1%	[3.3%, 4.5%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.7%, 1.3%]	2

Cycles

Results (secondary 3.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.0%	[1.9%, 4.5%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 764.328s -> 765.516s (0.16%)
Artifact size: 326.09 MiB -> 326.01 MiB (-0.03%)

The `#![start]` attribute has been removed in rust-lang/rust#134299.

`#![feature(start)]` was removed in [1], but we make use of it in the intrinsics example. Replace use of this feature with `#[no_mangle]` applied to `#[main]`. We don't actually run this example so it is not a problem if this is not entirely accurate. Currently the example does not run to completion, instead invoking `rust_begin_unwind`. [1]: rust-lang/rust#134299

…rors 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](rust-lang#29633 (comment)) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.* Closes rust-lang#29633 try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various

rustbot assigned compiler-errors Dec 14, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 14, 2024

RalfJung changed the title ~~remove support for the #[start] attribute~~ remove support for the (unstable) #[start] attribute Dec 14, 2024

RalfJung added the I-lang-nominated Nominated for discussion during a lang team meeting. label Dec 14, 2024