Tracking issue for the `start` feature

[aturon]

Tracking issue for #[start], which indicates that a function should be used as the entry point, overriding the "start" language item. In general this forgoes a bit of runtime setup that's normally run before and after main.

Open questions

• Is a panic leaving the start function UB? miri reports ub when panicing inside #[start] function #97049

[alexcrichton]

I believe the semantics of this today are that the compiler will generate a function with the symbol main which calls the #[start] function, if present, in an executable. This skips the #[lang = "start"] implementation, if any, in an upstream library (the standard library provides this to set up the first catch_panic among a few other minor things).

The signature for this function is also fn(isize, *const *const u8) -> isize, where the isize may no longer be "the most correct". Additionally, the *const *const u8 may not be the most appropriate option for Windows (although it works). I'm not 100% sure what "the best" signature on Windows is.

[retep998]

On Windows the executable entry point does not take any arguments. Currently we let the CRT act as the executable entry point which then calls our Rust entry wrapper which invokes the start function which is either #[lang = "start"] which then invokes the user's main function pointer provided to it or a user provided #[start] function. Which executable entry point the linker decides to use depends on the /SUBSYSTEM and which main function it can find (https://msdn.microsoft.com/en-us/library/f9t8842e.aspx). All information provided to the main function by the CRT can be obtained through alternative means. Note that if we eventually provide an option for /SUBSYSTEM:Windows that main function takes a very different set of (useless) arguments than the traditional main (https://msdn.microsoft.com/en-us/library/windows/desktop/ms633559%28v=vs.85%29.aspx).

[SimonSapin]

html5ever uses in an ugly hack that overrides the main function used by cargo test in order to generate thousands of tests dynamically. (Tests with the same code but parameterized on (input, expected result).)

This would be better solved by some way to override the test harness used by cargo test (Is there an issue/RFC for that already?)

[alexcrichton]

@SimonSapin the use case for that with Cargo should in theory be harness = false, but I'm curious how that interacts with #[start]?

[SimonSapin]

The #[start] trick doesn’t work anymore, but it looked like this: servo/html5ever@df8e749

Is there a tracking issue for harness = false?

[alexcrichton]

Oh that's already implemented today, if a test target is listed as harness = false then Cargo just won't pass --test when compiling it and expects it to be a binary.

(this may be a bit off-topic from #[start] though so feel free to ping me on IRC)

[mahkoh]

The current signature for the lang item is

fn lang_start(main: *const u8, argc: isize, argv: *const *const u8) -> isize {

which is called by a generated main function. Instead, the signatures of both should be arbitrary and the symbols translate to main directly. This allows the main function to be platform dependent. A pointer to the user's main function can be obtained via an intrinsic.

[retep998]

Note that on windows it really shouldn't always be main. If the user sets the subsystem to windows instead of console, then the CRT expects to find WinMain which results in a linker error because it wasn't defined.

[steveklabnik]

#20064 suggests that the signature here is wrong, we should consider this before making this feature stable.

[comex]

Just to clarify, it's not just a question of what signature lang_start should have; rustc currently generates C entry points (main) that only work "by accident" (because on 32-bit platforms isize = c_int and on 64-bit the calling conventions happen to work out). On my Mac, I get:

define i64 @main(i64, i8**) unnamed_addr {

Of course this would be an easy fix.

[retep998]

Just don't stabilize this until consideration is taken for subsystems, which change the entry point completely from main to WinMain and are really important for Rust to support if it wants to be used in the Windows world (several people have spoken to me and said this is one of the issues getting in the way of them using Rust in production on Windows)

[pravic]

Entry point name is irrelevant for windows apps actually. Ability to specify subsystem is one of important things to create application, because most of them are gui with "windows" subsystem.