Port `run-make/sysroot-crates-are-unstable` to rmake
I already have a more elaborate draft at #126231 that tries to port the underlying Python script to rmake, but there's no need for the removal of Makefiles to be held up on complex tasks like that, so this PR simply takes the trivial Makefile and converts it into a trivial rmake recipe.
Part of #121876.
r? ``@jieyouxu``
Migrate `remap-path-prefix-dwarf` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Possibly my proudest branch name yet.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-gnu-llvm-18
When a type comes indirectly from one crate version but the imported trait comes from a separate crate version, the called method won't be found. We now show additional context:
```
error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope
--> multiple-dep-versions.rs:8:10
|
8 | Type.foo();
| ^^^ method not found in `Type`
|
note: you have multiple different versions of crate `dependency` in your dependency graph
--> multiple-dep-versions.rs:4:32
|
4 | use dependency::{do_something, Trait};
| ^^^^^ `dependency` imported here doesn't correspond to the right crate version
|
::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
|
4 | pub trait Trait {
| --------------- this is the trait that was imported
|
::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:4:1
|
4 | pub trait Trait {
| --------------- this is the trait that is needed
5 | fn foo(&self);
| --- the method is available for `dep_2_reexport::Type` here
```
Fix warnings in rmake tests on `x86_64-unknown-linux-gnu`
r? `@jieyouxu`
This PR fixes some warnings I saw in rmake tests. I didn't deny more warnings in this PR until `@jieyouxu` gives their opinion, but maybe we should actually deny all warnings in `rmake.rs` files?
I've also only looked at non-ignored tests on `x86_64-unknown-linux-gnu`, and denying warnings would require a try build for all targets 😓.
run-make: explaing why fmt-write-bloat is ignore-windows
The trouble here is that libc doesn't exist on Windows. Well it kinda does but it isn't called that so we substitute a name that works. Ideally finding necessary libs for the platform would be done at a higher level but until then this should work.
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
run-make: enable msvc for staticlib-dylib-linkage
`-Zstaticlib-allow-rdylib-deps` on MSVC returns things like `/LIBPATH:R:\rust\build\x86_64-pc-windows-msvc\test\run-make\staticlib-dylib-linkage\rmake_out`. That is a linker argument rather than a `cc` argument. Which makes sense because rustc interacts directly with the linker on MSVC targets. So we need to tell the C compiler to pass on the arguments to the linker.
try-job: x86_64-msvc
try-job: i686-msvc
run-make: enable msvc for redundant-libs
The issue here was that `foo` was not exporting any functions therefore creating an import library was unnecessary and elided by the linker.
I fixed it by exporting the functions.
try-job: x86_64-msvc
try-job: i686-msvc
Add tests to ensure MTE tags are preserved across FFI boundaries
Added run-make tests to verify that, between a Rust-C FFI boundary in both directions, any MTE tags included in a pointer are preserved for the following pointer types, as well as any information stored using TBI:
- int
- float
- string
- function
try-job: aarch64-gnu
Migrate `pgo-gen-lto` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This one is so easy, I'm surprised I missed it.
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
Migrate `simd-ffi` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-17
Enable msvc for run-make/rust-lld
This is simply a matter of using the right argument for lld-link.
As a bonus, I also fixed a typo.
try-job: i686-msvc
try-job: x86_64-msvc
Migrate `cross-lang-lto-upstream-rlibs`, `long-linker-command-lines` and `long-linker-command-lines-cmd-exe` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The `long-linker` tests are certainly doing something... interesting - they summon `rustc` calls with obscene quantities of arguments and check that this is appropriately handled. I removed the `RUSTC_ORIGINAL` magic - it's equivalent to `RUSTC` in `tools.mk`, so what is the purpose? Making it so the massive pile of flags doesn't modify rustc itself and start leaking into other tests? Tell me what you think.
Please try:
try-job: x86_64-msvc
try-job: i686-msvc
try-job: x86_64-mingw
try-job: i686-mingw
try-job: aarch64-apple
try-job: test-various
try-job: x86_64-gnu-debug
try-job: x86_64-gnu-llvm-17
run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`
The common thing between these two tests is to use `#[link(..., kind="static")]` so that it doesn't try to do a DLL import.
`zero-extend-abi-param-passing` also needs to have an optimized static library but there's only helper function for a non-optimized version. Rather than copy/pasting the code (and adding the optimization flag) I reused the same code so that it more easily be kept in sync.
try-job: i686-msvc
try-job: x86_64-msvc
