Files
rust/tests/run-make
bors c8b7f32434 Auto merge of #140176 - dpaoliello:arm64ecdec, r=wesleywiser
Fix linking statics on Arm64EC

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
2025-05-09 00:43:28 +00:00
..
2025-04-06 21:41:47 +02:00
2025-04-06 21:41:47 +02:00
2024-06-07 11:12:04 +02:00
2024-07-17 13:34:18 +00:00
2024-08-15 15:44:29 +02:00
2024-07-17 13:34:18 +00:00
2025-03-31 10:41:10 +02:00
2024-08-15 15:44:29 +02:00
2024-07-17 13:34:18 +00:00
2024-07-29 14:33:54 -04:00
2024-09-05 08:43:38 +00:00
2024-07-29 08:26:52 +10:00
2024-06-25 14:27:43 -04:00
2024-05-28 11:41:53 -04:00
2024-07-18 09:28:30 -04:00
2024-07-17 13:34:18 +00:00
2024-07-17 13:34:18 +00:00
2024-07-17 13:34:18 +00:00
2024-07-29 08:26:52 +10:00
2025-03-09 07:56:41 +00:00
2024-07-29 08:26:52 +10:00
2024-07-17 13:34:18 +00:00
2024-08-15 15:44:29 +02:00
2024-09-05 08:43:38 +00:00
2024-09-05 08:43:38 +00:00
2024-11-30 16:29:49 +08:00
2024-08-03 13:02:32 +00:00
2025-02-08 22:12:13 +00:00
2024-07-29 08:26:52 +10:00
2025-03-02 05:56:56 +08:00

The run-make test suite

The run-make test suite contains tests which are the most flexible out of all the rust-lang/rust test suites. run-make tests can basically contain arbitrary code, and are supported by the run_make_support library.

Infrastructure

A run-make test is a test recipe source file rmake.rs accompanied by its parent directory (e.g. tests/run-make/foo/rmake.rs is the foo run-make test).

The implementation for collecting and building the rmake.rs recipes are in src/tools/compiletest/src/runtest.rs, in run_rmake_test.

The setup for the rmake.rs can be summarized as a 3-stage process:

  1. First, we build the run_make_support library in bootstrap as a tool lib.

  2. Then, we compile the rmake.rs "recipe" linking the support library and its dependencies in, and provide a bunch of env vars. We setup a directory structure within build/<target>/test/run-make/

    <test-name>/
        rmake.exe              # recipe binary
        rmake_out/             # sources from test sources copied over
    

    and copy non-rmake.rs input support files over to rmake_out/. The support library is made available as an extern prelude.

  3. Finally, we run the recipe binary and set rmake_out/ as the working directory.