| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
To avoid blocking full CI.
|
|
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`.
|
|
Rollup of 6 pull requests
Successful merges:
- #128990 (Re-enable more debuginfo tests on freebsd)
- #129042 (Special-case alias ty during the delayed bug emission in `try_from_lit`)
- #129086 (Stabilize `is_none_or`)
- #129149 (Migrate `validate_json.py` script to rust in `run-make/rustdoc-map-file` test)
- #129154 (Fix wrong source location for some incorrect macro definitions)
- #129161 (Stabilize std::thread::Builder::spawn_unchecked)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`run-make` tests
|
|
|
|
|
|
|
|
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
|
|
Migrate `rlib-format-packed-bundled-libs` and `native-link-modifier-bundle` `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: test-various (ATTEMPTED: IGNORE RESTORED)
try-job: x86_64-msvc
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: x86_64-mingw
try-job: i686-mingw
|
|
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](https://github.com/rust-lang/rust/pull/13288/commits/0d9fd8e2a1f8aa43b4cf66272eaa3cf695bbdcd9) 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
|
|
GuillaumeGomez:remove-duplicated-rustdoc-output-methods, r=Kobzol
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`
|
|
|
|
|
|
|
|
Support reading thin archives in ArArchiveBuilder
And switch to using ArArchiveBuilder with the LLVM backend too now that all regressions are fixed.
Fixes https://github.com/rust-lang/rust/issues/107407
Fixes https://github.com/rust-lang/rust/issues/107162
https://github.com/rust-lang/rust/issues/107495 has been fixed in a previous PR already.
|
|
|
|
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
|
|
|
|
|
|
run-make API
|
|
|
|
|
|
|
|
|
|
Remove unused script from run-make tests
Its last usage was removed in https://github.com/rust-lang/rust/pull/128636.
Tracking issue: https://github.com/rust-lang/rust/issues/121876
r? jieyouxu
|
|
|
|
Make checking slightly cheaper (by restricting to the right item only).
Add tests.
|
|
|
|
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 😓.
|
|
|
|
|
|
|
|
|
|
|
|
|
