Regression in `#[used]` attribute on Windows msvc

[ehuss]

Code

I tried this code:

#[used]
static FOO: u32 = 0;
fn main() {}

I expected to see this happen: Compiles successfully.

Instead, this happened: Fails with this error:

  = note: symbols.o : error LNK2001: unresolved external symbol _ZN3foo3FOO17h3b276d94f7182e74E
          D:\Temp\foo\target\debug\deps\foo.exe : fatal error LNK1120: 1 unresolved externals

Version it worked on

nightly-2024-06-26 and earlier.

Version with regression

nightly-2024-06-27 and later, starting with #126938.
See #126938 (comment) for a discussion of the issue.

rustc --version --verbose:

rustc 1.81.0-nightly (4bc39f028 2024-06-26)
binary: rustc
commit-hash: 4bc39f028d14c24b04dd17dc425432c6ec354536
commit-date: 2024-06-26
host: x86_64-pc-windows-msvc
release: 1.81.0-nightly
LLVM version: 18.1.7

cc @RalfJung @ChrisDenton

[ChrisDenton]

To elaborate, the difference is in symbols.o.

Here's a dump of symbols.o before the change:

COFF SYMBOL TABLE
000 00000000 ABS    notype       Static       | @feat.00
001 00000000 UNDEF  notype ()    External     | main
002 00000000 UNDEF  notype ()    External     | rust_eh_personality
003 00000000 UNDEF  notype ()    External     | rust_begin_unwind
004 00000000 UNDEF  notype ()    External     | rust_eh_personality
005 00000000 UNDEF  notype ()    External     | __rust_alloc
006 00000000 UNDEF  notype ()    External     | __rust_dealloc
007 00000000 UNDEF  notype ()    External     | __rust_realloc
008 00000000 UNDEF  notype ()    External     | __rust_alloc_zeroed

And here's after:

COFF SYMBOL TABLE
000 00000000 ABS    notype       Static       | @feat.00
001 00000000 UNDEF  notype       External     | _ZN3foo3FOO17hff4b2214a6243215E
002 00000000 UNDEF  notype ()    External     | main
003 00000000 UNDEF  notype ()    External     | rust_eh_personality
004 00000000 UNDEF  notype ()    External     | rust_begin_unwind
005 00000000 UNDEF  notype ()    External     | rust_eh_personality
006 00000000 UNDEF  notype ()    External     | __rust_alloc
007 00000000 UNDEF  notype ()    External     | __rust_dealloc
008 00000000 UNDEF  notype ()    External     | __rust_realloc
009 00000000 UNDEF  notype ()    External     | __rust_alloc_zeroed

Spot the difference. Spoiler: _ZN3foo3FOO17hff4b2214a6243215E is now present.

[RalfJung]

So is that right or wrong? The static is "used" so marking it exported to ensure it does not get optimized away seems to make sense? I don't understand why this is a problem only on Windows.

[ChrisDenton]

Well that's not a problem per se but if we want to do that then we have to do it properly. _ZN3foo3FOO17hff4b2214a6243215E is defined as a STATIC in foo.eopdl1t2ep4vx19njs4kilajt.rcgu.o (on my machine). This is linked directly and not in a lib file. So it's already being included. There's no reason for symbols.o to include it.

The only issue is that FOO is being emitted as a comdat, meaning the linker is still allowed to remove it. We could just not do that (or add a /include linker directive). But that's a pre-existing issue.

[RalfJung]

I don't understand any part of that.^^ Should my PR get reverted or is there a better way to fix this regression? If there is a better way, I am afraid I lack the knowledge to implement and test it. I don't understand symbol handling on Linux, let alone on Windows.

[ChrisDenton]

I don't know enough about the Rust compiler to say. My complete guess would be that used was silently broken before but now it's nosily broken.

[RalfJung]

Hm, who would understand our Windows linking story? @bjorn3 ?