Fix linking statics on Arm64EC

[dpaoliello]

Arm64EC builds recently started to fail due to the linker not finding a symbol:

symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
          C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals

It turns out that EMPTY_PANIC is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with # (as only functions are prefixed with this character), whereas Rust was prefixing with # when attempting to import it.

The fix is to have Rust not prefix statics with # when importing.

Adding tests discovered another issue: we need to correctly mark static exported from dylibs with DATA, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.

CI found another bug: we only apply DllImport to non-local statics that aren't foreign items (i.e., in an extern block), that is we want to use DllImport for statics coming from other Rust crates. However, __rust_no_alloc_shim_is_unstable is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an extern "Rust" block, thus they do not apply DllImport to it and so fails to link if it is exported by the previous crate as DATA. The fix is to apply DllImport to foreign items that are marked with the rustc_std_internal_symbol attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).

Fixes #138541

---

try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2

[rustbot]

r? @Nadrieril

rustbot has assigned @Nadrieril.
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]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[wesleywiser]

Changes look good to me. Is it possible to write a regression test? (Either a full-scale integration test that links an exported static from one crate to another or a test that imports a static and dumps the symbol name or something?)

[Nadrieril]

r? @wesleywiser

[wesleywiser]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[dpaoliello]

Changes look good to me. Is it possible to write a regression test? (Either a full-scale integration test that links an exported static from one crate to another or a test that imports a static and dumps the symbol name or something?)

Good call, found another bug: we need to correctly export variables as DATA otherwise the linker expects them to have thunks.

@rustbot ready

[wesleywiser]

Thanks @dpaoliello!

@bors r+ rollup

Also nominating for potential beta backport as this fixes a serious issue for the Tier 2 aarch64-pc-windows-msvc.

[bors]

📌 Commit 7370c5c has been approved by wesleywiser

It is now in the queue for this repository.

[dpaoliello]

Verified with a modified PR job: https://github.com/rust-lang/rust/actions/runs/14870437710/job/41757432246?pr=140176

@rustbot ready

[wesleywiser]

@bors r+

[bors]

📌 Commit 6dabf7e has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

⌛ Testing commit 6dabf7e with merge c8b7f32...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing c8b7f32 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 667247d (parent) -> c8b7f32 (this PR)

Test differences

Show 3 test diffs

Stage 1

• [run-make] tests/run-make/arm64ec-import-export-static: [missing] -> ignore (only executed when the operating system is windows) (J2)

Stage 2

• [run-make] tests/run-make/arm64ec-import-export-static: [missing] -> ignore (only executed when the operating system is windows) (J0)
• [run-make] tests/run-make/arm64ec-import-export-static: [missing] -> pass (J1)

Job group index

• J0: aarch64-apple, aarch64-gnu, aarch64-gnu-debug, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, dist-various-1, i686-gnu-1, i686-gnu-nopt-1, test-various, x86_64-apple-1, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable
• J1: i686-msvc-1, x86_64-mingw-1, x86_64-msvc-1
• J2: x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard c8b7f32434c0306db5c1b974ee43443746098a92 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-apple-2: 5691.9s -> 7352.0s (29.2%)
2. dist-aarch64-apple: 4681.1s -> 5540.7s (18.4%)
3. dist-apple-various: 7341.5s -> 8598.3s (17.1%)
4. dist-x86_64-apple: 8512.9s -> 9239.2s (8.5%)
5. x86_64-gnu-llvm-19-1: 5602.0s -> 5282.1s (-5.7%)
6. dist-loongarch64-linux: 6275.5s -> 6603.6s (5.2%)
7. x86_64-apple-1: 7275.7s -> 7608.8s (4.6%)
8. dist-x86_64-netbsd: 4966.2s -> 5169.5s (4.1%)
9. mingw-check: 1249.4s -> 1298.6s (3.9%)
10. dist-i686-mingw: 7957.4s -> 7664.6s (-3.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (c8b7f32): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 0.1%, secondary 0.2%)

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.6%	[0.4%, 6.5%]	8
Regressions ❌ (secondary)	5.4%	[5.4%, 5.4%]	1
Improvements ✅ (primary)	-1.5%	[-5.0%, -0.5%]	8
Improvements ✅ (secondary)	-1.5%	[-1.9%, -1.1%]	3
All ❌✅ (primary)	0.1%	[-5.0%, 6.5%]	16

Cycles

Results (primary 0.1%, secondary -2.8%)

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.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-2.8%	[-2.8%, -2.8%]	1
All ❌✅ (primary)	0.1%	[-0.4%, 0.6%]	2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 771.655s -> 771.811s (0.02%)
Artifact size: 365.39 MiB -> 365.31 MiB (-0.02%)