Skip to content

Consider adding a //@ needs-std directive for target std support #141863

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jieyouxu opened this issue Jun 1, 2025 · 0 comments · Fixed by #142297
Closed

Consider adding a //@ needs-std directive for target std support #141863

jieyouxu opened this issue Jun 1, 2025 · 0 comments · Fixed by #142297
Labels
A-compiletest Area: The compiletest test runner A-compiletest-directives Area: compiletest directives C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jieyouxu
Copy link
Member

jieyouxu commented Jun 1, 2025

Hmm, that directive is never actually used, and also does not solve the issue for that target. It is a known target, just not one that has std (just core I assume). None of the directives in the list seem to really capture this? Maybe needs-threads is a decent proxy but that's not ideal.

-- #141856 (comment)

and

Yeah, a proper fix is sth like //@ needs-std, but for this PR, //@ ignore-none is a proxy for ignoring the *-unknown targets. I suppose //@ ignore-nvptx is better tho.

Originally posted by @jieyouxu in #141856 (comment)

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jun 1, 2025
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-compiletest Area: The compiletest test runner A-compiletest-directives Area: compiletest directives C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jun 1, 2025
rust-bors bot added a commit that referenced this issue 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 issue 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 issue 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 issue 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 issue 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"
@bors bors closed this as completed in 57bb38b Jun 11, 2025
rust-timer added a commit that referenced this issue 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 issue 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"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-compiletest-directives Area: compiletest directives C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants