[WIP] [WIP] Enable automatic cross-compilation in run-make tests #139244
+127
−53
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
A-run-make
jieyouxu
added
S-experimental
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 2, 2025
…<try> [WIP] [WIP] Enable automatic cross-compilation in run-make tests WIP for the WIP rust-lang#138066. Based on rust-lang#138066 with rust-lang#139242 + rust-lang#139239 cherry-picked in, plus `rustdoc()` cross-compile changes. r? `@ghost` try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: i686-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
bors
added
the
S-waiting-on-author
|
☔ The latest upstream changes (presumably #139257) made this pull request unmergeable. Please resolve the merge conflicts. |
jieyouxu
force-pushed
the
exp/auto-cross-run-make
branch
from
c09efec to
9140e31
Compare
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 4, 2025
…<try> [WIP] [WIP] Enable automatic cross-compilation in run-make tests WIP for the WIP rust-lang#138066. Based on rust-lang#138066 with rust-lang#139242 + rust-lang#139239 cherry-picked in, plus `rustdoc()` cross-compile changes. r? `@ghost` try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: i686-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
|
Aaaaa I accidentally clicked again 💀 |
jieyouxu
removed
the
S-waiting-on-author
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
|
☔ The latest upstream changes (presumably #139242) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
added
the
S-waiting-on-author
jieyouxu
force-pushed
the
exp/auto-cross-run-make
branch
from
9140e31 to
520d534
Compare
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 13, 2025
…=<try> [WIP] Enable automatic cross-compilation for run-make rustdoc tests Extracted out of rust-lang#139244. Helps with rust-lang#138066. r? `@ghost` try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 13, 2025
…<try> [WIP] [WIP] Enable automatic cross-compilation in run-make tests WIP for the WIP rust-lang#138066. Based on rust-lang#138066 with rust-lang#139242 + rust-lang#139239 cherry-picked in, plus `rustdoc()` cross-compile changes. r? `@ghost` try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
jieyouxu
force-pushed
the
exp/auto-cross-run-make
branch
from
676eada to
8d6ff0e
Compare
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 19, 2025
…<try> [WIP] [WIP] Enable automatic cross-compilation in run-make tests WIP for the WIP rust-lang#138066. Based on rust-lang#138066 with rust-lang#139242 + rust-lang#139239 cherry-picked in, plus `rustdoc()` cross-compile changes. r? `@ghost` try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
jieyouxu
force-pushed
the
exp/auto-cross-run-make
branch
from
8d6ff0e to
150c4cc
Compare
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 19, 2025
…<try> [WIP] [WIP] Enable automatic cross-compilation in run-make tests WIP for the WIP rust-lang#138066. Based on rust-lang#138066 with rust-lang#139242 + rust-lang#139239 cherry-picked in, plus `rustdoc()` cross-compile changes. r? `@ghost` try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple try-job: x86_64-apple-1
|
💔 Test failed - checks-actions |
|
💀 |
|
most of the failing tests are for Although, given that normal CI does not cross-compile the tests, it's really easy to add a new |
rust-bors bot
added a commit
that referenced
this pull request
Jun 10, 2025
Implement `//@ needs-target-std` compiletest directive Closes #141863. Needed to unblock #139244 and #141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with #139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std" try-job: test-various try-job: armhf-gnu
fmease
added a commit
to fmease/rust
that referenced
this pull request
Jun 10, 2025
Implement `//@ needs-target-std` compiletest directive Closes rust-lang#141863. Needed to unblock rust-lang#139244 and rust-lang#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 11, 2025
Implement `//@ needs-target-std` compiletest directive Closes rust-lang#141863. Needed to unblock rust-lang#139244 and rust-lang#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 11, 2025
Implement `//@ needs-target-std` compiletest directive Closes rust-lang#141863. Needed to unblock rust-lang#139244 and rust-lang#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 11, 2025
Implement `//@ needs-target-std` compiletest directive Closes rust-lang#141863. Needed to unblock rust-lang#139244 and rust-lang#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 11, 2025
Implement `//@ needs-target-std` compiletest directive Closes rust-lang#141863. Needed to unblock rust-lang#139244 and rust-lang#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
rust-timer
added a commit
that referenced
this pull request
Jun 11, 2025
Rollup merge of #142297 - jieyouxu:needs-target-std, r=Kobzol Implement `//@ needs-target-std` compiletest directive Closes #141863. Needed to unblock #139244 and #141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with #139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
github-actions bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Jun 12, 2025
Implement `//@ needs-target-std` compiletest directive Closes rust-lang/rust#141863. Needed to unblock rust-lang/rust#139244 and rust-lang/rust#141856. ### Summary This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit]. ### Implementation limitation Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang/rust#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`. ### Auxiliary changes This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang/rust#139244. --- r? bootstrap [^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
rust-bors bot
added a commit
that referenced
this pull request
Jun 12, 2025
ignore `run-make` tests that need `std` on targets without `std` In particular, anything that includes `none` in the target triple, and `nvptx64-nvidia-cuda`. Right now we don't cross-compile the `run-make` tests, but we want to in the future. This uses `//@ needs-target-std` introduced in #142297. Useful for #139244 and #141856. The modified files are based on running #141856 locally. It might be that #139244 uncovers some additional files, but that PR needs to be rebased (though actually I'd advice to rebase the non-test changes onto this PR, probably faster that way). r? `@jieyouxu` <details> <summary>vim notes for future me</summary> Make a file with lines like this ``` /home/folkertdev/rust/rust/tests/run-make/export/disambiguator/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/invalid-so/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/no-builtins-attribute/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/export/extern-opt/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/link-dedup/rmake.rs:1:1 ``` then ``` :set errorformat=%f:%l:%c :cfile /tmp/files-to-fix.txt ``` ``` :copen :cnext :cprev ``` are your friends </details> try-job: test-various try-job: armhf-gnu
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WIP for the WIP #138066.
Blocker for #141856.
Based on #138066 with #139242 + #139239 cherry-picked in, plus
rustdoc()cross-compile changes.r? @ghost
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: aarch64-apple
try-job: x86_64-apple-1