`#![windows_subsystem = "windows"]` overwrites entrypoint symbol name

[MauriceKayser]

Description

Using #![windows_subsystem = "windows"] overwrites the default entrypoint symbol name WinMainCRTStartup with mainCRTStartup. This is by design, but can be unexpected in certain scenarios, for example when specifying #![no_main]. It should either be adapted for those scenarios, or mentioned in the user facing documentation.

Reproduction

1. Create example.rs:

   #![no_main]
   #![no_std]
   
   #[cfg(not(test))]
   #[panic_handler]
   fn panic(_: &core::panic::PanicInfo) -> ! {
       loop {}
   }
   
   #[unsafe(no_mangle)]
   extern "system" fn WinMainCRTStartup() -> i32 {
       0
   }

2. Linking succeeds via: rustc example.rs -C panic=abort -C link-arg=/Subsystem:Windows
3. Add #![windows_subsystem = "windows"] to example.rs
4. Linking fails via: rustc example.rs -C panic=abort

[workingjubilee]

We probably should just error on the attempt to use both #![windows_subsystem = "windows"] and #![no_main], actually.

[workingjubilee]

My reasoning is that #![windows_subsystem = "windows"], while a "global" attribute, is in some sense an attribute designed to steer how we handle fn main(). If you are interested in seizing control of the entry points by defining raw symbols, we are mostly going to get in your way.

[Fulgen301]

We probably should just error on the attempt to use both #![windows_subsystem = "windows"] and #![no_main], actually.

I'd rather propose not setting the entrypoint at all if #![no_main] and going with the defaults for the selected subsystem - the reason Rust overwrites the platform defaults is that Rust generates a main function as opposed to a WinMain function even with the Windows subsystem. With #![no_main], the user explicitely opts out of Rust providing a main function and uses whatever the rest of the configuration happens to require, so there's no reason for #![windows_subsystem = "windows"] to mess with the entrypoint.

[workingjubilee]

@Fulgen301 invalid configurations should produce explicit errors where reasonable.

[workingjubilee]

We don't know if you started with #![windows_subsystem = "windows"] or #![no_main]. Prioritizing one and deciding it matters "more", instead of simply producing an error, requires us to have psychic powers or the arrogance to assume we know which is best. No one is adding these attributes via macros or anything: they will be explicit decisions.

[Fulgen301]

The error appears because Rust has extra logic in handling windows_subsystem that overwrites the platform's default entry point for /SUBSYSTEM:WINDOWS. What the user wanted was to set the subsystem to windows, via the attribute that is documented as

The windows_subsystem attribute may be applied at the crate level to set the subsystem when linking on a Windows target.

, and write their own entrypoint according to the platform's defaults by specifying #![no_main], thus opting out of Rust providing an entrypoint - and then they run into Rust messing with the platform's defaults.

The explicit decisions taken by the user were

• I want the Windows subsystem
• I don't want Rust to provide me with an entrypoint

- the only reason it errors is that Rust still decides it needs to change the entry point to what it needs for its main function, instead of using the target's well-documented defaults like any other target despite the user explicitely opting out of the compiler providing said main function. (Which ironically is rustc assuming that it knows what is best even with the user telling it otherwise.)

And telling users "Sorry, you need to manually pass /SUBSYSTEM:WINDOWS instead of using #[!subsystem = "windows"] or use that attribute and pass /ENTRY:WinMainCRTStartup to the linker because Rust changes the entry point for what it needs for its main function despite you indicating you don't want a main function via no_main" is not a great user experience.