Migrate `x86_64-fortanix-unknown-sgx-lvi` `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).
The final Makefile! Every Makefile test is now claimed.
This is difficult to test due to the uncommon architecture it is specific to. I don't think it is in the CI (I didn't find it in `jobs.yml`, but if there is a way to test it, please do.
Locally, on Linux, it compiles and panics at the `llvm_filecheck` part (if I replace the `x86_64-fortanix-unknown-sgx` with `x86_64-unknown-linux-gnu`, of course), which is expected.
For this reason, the Makefile and associated script have been kept, but with a leading underscore.
Allow rust staticlib to work with MSVC's /WHOLEARCHIVE
This fixes#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts.
try-job: dist-i686-msvc
Trying to get rid of this Python script looks tempting, because it's currently
the only Python script in the whole `run-make` suite that we actually run.
But getting rid of it would require pulling in a Rust crate to parse XML
instead, and that's probably not worth the extra hassle for a relatively-minor
test.
Disable `dump-ice-to-disk` for i686-mingw (again)
To avoid blocking full CI or `i686-mingw` try jobs (failed in https://github.com/rust-lang/rust/pull/127679#issuecomment-2295184771).
At least we now have some context for why the assertion failed.
Anyone with r+ can approve this.
Port `run-make/libtest-json/validate_json.py` to Rust
This is a trivial Python script that simply tries to parse each line of stdin (i.e. the test process output) as JSON, to verify that the overall output is JSON Lines.
We can perform the same check directly in `rmake.rs` using `serde_json`.
r? ````@jieyouxu````
Re-enable `dump-ice-to-disk` for Windows
This test was previously flakey on `i686-mingw` (reason unknown), but since some modifications (quarantining each ICE test in separate tmp dirs, adding/removing `RUSTC_ICE` env vars as suitable to prevent any kind of environmental influence), I could no longer make it fail on `i686-mingw`.
I tried running this test (without the `ignore-windows` of course) a bunch of times via `i686-mingw` try jobs and it refused to fail (see #128958). I was also never able to reproduce the failure locally.
In any case, if this turns out to be still flakey on `i686-mingw`, we can revert the removal of `ignore-windows` but this time we'll have way more context for why the test failed.
Running the `i686-mingw` alongside some Windows jobs for basic santiy check. But the try jobs succeeding is insufficient to guarantee reproducibility.
cc #129115 for backlink.
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
Detect multiple crate versions on method not found
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: there are multiple different versions of crate `dependency` in the 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#128569, fix#110926, fix#109161, fix#81659, fix#51458, fix#32611. Follow up to #124944.
This is a trivial Python script that simply tries to parse each line of stdin
(i.e. the test process output) as JSON, to verify that the overall output is
JSON Lines.
We can perform the same check directly in `rmake.rs` using `serde_json`.
Port the `sysroot-crates-are-unstable` Python script to rmake
New version of #126231, and a follow-up to #129071.
One major difference is that the new version no longer tries to report *all* accidentally-stable crates, because the `run_make_support` helpers tend to halt the test as soon as something goes wrong. That's unfortunate, but I think it won't matter much in practice, and preserving the old behaviour doesn't seem worth the extra effort.
---
Part of #110479 (Python purge), with this being one of the non-trivial Python scripts that actually seems feasible and worthwhile to remove.
This is *not* part of #121876 (Makefile purge), because the underlying test is already using rmake; this PR just modifies the existing rmake recipe to do all the work itself instead of delegating to Python. So there's no particular urgency here.
r? ````@jieyouxu````
try-job: aarch64-gnu
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: i686-mingw
Port `run-make/libtest-json` and `run-make/libtest-junit` to rmake
Unlike #126773, this is just a straightforward port to `rmake`, without attempting to switch to compiletest or get rid of the (trivial) Python scripts.
Part of #121876.
r? ````@jieyouxu````
try-job: x86_64-msvc
try-job: i686-mingw
try-job: test-various
try-job: aarch64-gnu
try-job: aarch64-apple
Coalesce `dep-info`, `dep-info-spaces` and `dep-info-doesnt-run-much` `run-make` tests into `dep-info` rmake.rs
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 is one of the most ancient tests in the `run-make` directory and its Makefile does some unexpected things, like creating and deleting a `done` directory over and over, sleeping at certain times (this is the [commit](0d9fd8e2a1) that added the `sleep`).
I tried to preserve the intent of the test, which is smoke-testing that `dep-info` works.
try-job: x86_64-msvc
try-job: i686-mingw
try-job: aarch64-gnu
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: dist-various-1
Remove duplicated `Rustdoc::output` method from `run-make-support` lib
I discovered recently that `--output` is deprecated in rustdoc and that `--out-dir` is doing the exact same thing. To keep things along with the current rustdoc status, I removed the `Rustdoc::output` method.
cc `@jieyouxu`
r? `@Kobzol`
This test was previously flakey on `i686-mingw`, but since some
modifications I could no longer make it fail on `i686-mingw`.
See <https://github.com/rust-lang/rust/pull/128958> for multiple try
job runs.
Add possibility to generate rustdoc JSON output to stdout
Fixes#127165.
I think it's likely common to want to get rustdoc json output directly instead of reading it from a file so I added this option to allow it. It's unstable and only works with `--output-format=json`.
r? `@aDotInTheVoid`
Migrate `min-global-align` and `no-alloc-shim` `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).
Please try:
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-gnu
try-job: aarch64-gnu
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
