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

[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.

[joshtriplett]

Temporarily shuffling labels around in order to run an FCP.

[joshtriplett]

This is unstable, and TTBOMK isn't part of any accepted RFC.

I'm sad to see it go, but I agree that in its current form it may not make sense to support. I'd love to see a design proposal for a portable version, but the current #[start] isn't it.

👍 for removing it.

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• check-with-embedded-folks (remove support for the (unstable) #[start] attribute #134299 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[joshtriplett]

@rfcbot concern check-with-embedded-folks

I would like to get some indication from folks who know the embedded community well to make sure this isn't something widely used. Even though it's a nightly feature, I know that some embedded development does use nightly, and I'd like to get some kind of affirmative indication from at least one person who knows the embedded community well to confirm that this isn't one of the mechanisms used. To the best of my knowledge, it's more common to use things like a #[no_mangle] main function, but I'm not an expert in current embedded Rust.

ping @jamesmunns @BartMassey?

[joshtriplett]

Marking this as I-lang-easy-decision, conditional on hearing back from embedded folks that this isn't widely used. Assuming that's the case, this is a nightly feature, and removing it shouldn't be too controversial.

[jamesmunns]

Pinged in chat, we just started our two week break for regular meetings, I'll ping back here if I hear any objections.

[berkus]

Not speaking for the whole embedded community but this is the first time I read about #[start] - have never ever seen it in any embedded software in rust.

[jamesmunns]

Also grep app only finds like four projects on github that seem to use this attribute (outside of UI tests, etc.): https://grep.app/search?q=%23%5Bstart%5D&filter[lang][0]=Rust - none of them embedded specific.

• https://github.com/mlund/mos-hardware (seems active)
• https://github.com/codyd51/axle - (somewhat active)
• https://github.com/privacy-scaling-explorations/zkevm-circuits (archived)
• https://github.com/ipetkov/crane (seems active)

edit, found some more:

• https://github.com/FractalFir/rustc_codegen_clr
• https://github.com/serde-rs/serde/blob/master/test_suite/no_std/src/main.rs
• https://github.com/rune-rs/rune/blob/main/no-std/examples/minimal.rs
• https://github.com/smackers/smack/blob/main/test/rust/panic/core_panic_fail.rs
• https://github.com/thepowersgang/rust_os/blob/master/Usermode/hello_world/src/main.rs
• https://github.com/gz/rust-x86/blob/master/tests/no_std_build.rs
• https://github.com/tomaka/redshirt/blob/main/programs/stub/src/main.rs
• https://github.com/GaloisInc/crucible/blob/master/crux-mir/lib/compiler_builtins/examples/intrinsics.rs
• https://github.com/yaahc/displaydoc
• https://github.com/udoprog/musli

(and some more if you keep digging through "Load More Results", I don't think this is a blocker, and there are likely other ways to achieve this)

Not sure if we want to ping those users, but more as a "heads up your code is going to break".

Either way, it's not used in the embedded wg's crates, but it does seem to be used in a handful of bare metal kernel/OS projects. It would probably be good to have a diagnostic that explains (or links to an explanation) of what to do instead.

[RalfJung]

I filed a bunch of issues pointing here, so if any of these uses is critical, people will hopefully show up and tell us about it.

[nikomatsakis]

@rfcbot reviewed

[traviscross]

@rfcbot reviewed