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

[RalfJung]

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]

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]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[RalfJung]

@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]

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]

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

[RalfJung]

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]

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]

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

[RalfJung]

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]

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

[RalfJung]

@bors r=compiler-errors

[bors]

📌 Commit 91b8386 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit 91b8386 with merge 2ffb3ba...

[bors]

💔 Test failed - checks-actions

[RalfJung]

@bors try

[bors]

⌛ Trying commit 56c90dc with merge edf68bb...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

x86_64-gnu-nopt
test-various
x86_64-msvc
##[endgroup]
INFO:root:Job type: TryRunType(custom_jobs=['x86_64-gnu-nopt', 'test-various', 'x86_64-msvc'])
  File "/home/runner/work/rust/rust/src/ci/github-actions/ci.py", line 314, in <module>
    calculate_job_matrix(data)
  File "/home/runner/work/rust/rust/src/ci/github-actions/ci.py", line 266, in calculate_job_matrix
  File "/home/runner/work/rust/rust/src/ci/github-actions/ci.py", line 266, in calculate_job_matrix
    jobs = calculate_jobs(run_type, job_data)
  File "/home/runner/work/rust/rust/src/ci/github-actions/ci.py", line 153, in calculate_jobs
    raise Exception(
    raise Exception(
Exception: Custom job(s) `['x86_64-msvc']` not found in auto jobs
##[error]Process completed with exit code 1.

[RalfJung]

@rust-lang/infra I got "The job x86_64-msvc failed!" but now that same job name does not work in a try build...?

[jieyouxu]

@RalfJung you want x86_64-msvc-1 now

[RalfJung]

Ah I guess I managed to race with #135632. There is -1 and -2 and I don't know which one got the test that failed before so I guess I should add both.

[RalfJung]

@bors try

[bors]

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

[bors]

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

[RalfJung]

@bors r=compiler-errors

[bors]

📌 Commit 56c90dc has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit 56c90dc with merge ed43cbc...

[rust-highfive]

📣 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).

[bors]

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

[rust-timer]

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%)