Fix "std" support status of some tier 3 targets #133867

taiki-e · 2024-12-04T18:48:54Z

#127265 marked targets with empty "std" support status as no-std targets in target-spec metadata:

Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build

However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.)

https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3

The std column in the table below has the following meanings:

✓ indicates the full standard library is available.

* indicates the target only supports no_std development.

? indicates the standard library support is unknown or a work-in-progress.

This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata.

The new status is set based on the following criteria:

Set to ✓ for targets that I regularly check in rust-cross-toolchain that the cargo test works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl)
- Targets where cargo run works but cargo test does not work tend to have incomplete std support (e.g., riscv32 musl taiki-e/rust-cross-toolchain@f3068b6), so I included them in the group below that means “work in progress” rather than in this group.
Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the Rust package is available.
Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported.

r? Noratrieb
cc @harmou01

rustbot · 2024-12-04T18:49:05Z

These commits modify compiler targets.
(See the Target Tier Policy.)

Noratrieb · 2024-12-04T19:06:46Z

compiler/rustc_target/src/spec/targets/powerpc64le_unknown_freebsd.rs

@@ -13,7 +13,7 @@ pub(crate) fn target() -> Target {
            description: Some("PPC64LE FreeBSD".into()),
            tier: Some(3),
            host_tools: Some(false),
-            std: Some(false),
+            std: None,


Suggested change

std: None,

std: Some(true),

it's FreeBSD

As #127265 did, when "std" support status is “?” I used “None”, but is FreeBSD special?

In fact, in powerpc64le, the Rust package is available, so both std and host_tools should be Some(true). On the other hand, the Rust package for powerpc and riscv does not seem to be available, so I guess None (unknown) is appropriate.

Updated powerpc64le freebsd target spec.

FreeBSD is an operating system supported by std, and so is Linux and Fuchsia. Can you set all those to true?

Marked all Linux/Android/BSD/Fuchsia as supporting "std" in target-spec metadata.

(I was set them to None because I thought there is a plan to mechanically synchronize them with platform-support.md (the status of targets with work-in-progress std support is “?” in platform-support.md, and I thought “None” in metadata would correspond to this), but if not, I think it is reasonable to set them to true since they are “targets where std support is expected to eventually be available even if currently work-in-progress”.)

compiler/rustc_target/src/spec/targets/powerpc_unknown_freebsd.rs

compiler/rustc_target/src/spec/targets/riscv64gc_unknown_freebsd.rs

… metadata

Noratrieb · 2024-12-05T06:19:57Z

@bors r+ rollup

bors · 2024-12-05T06:20:00Z

📌 Commit e3638e2 has been approved by Noratrieb

It is now in the queue for this repository.

Fix "std" support status of some tier 3 targets rust-lang#127265 marked targets with empty "std" support status as no-std targets in target-spec metadata: > * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.) https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3 > The `std` column in the table below has the following meanings: > > * ✓ indicates the full standard library is available. > * \* indicates the target only supports [`no_std`] development. > * ? indicates the standard library support is unknown or a work-in-progress. > > [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata. The new status is set based on the following criteria: - Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl) - Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl taiki-e/rust-cross-toolchain@f3068b6), so I included them in the group below that means “work in progress” rather than in this group. - Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available. - Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported. r? Noratrieb cc `@harmou01`

Rollup of 6 pull requests Successful merges: - rust-lang#127565 (Teach rustc about the Xtensa VaListImpl) - rust-lang#133844 (clarify simd_relaxed_fma non-determinism) - rust-lang#133867 (Fix "std" support status of some tier 3 targets) - rust-lang#133882 (Improve comments for the default backtrace printer) - rust-lang#133888 (Improve bootstrap job objects) - rust-lang#133898 (skip `setup::Hook` on non-git sources) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#133867 - taiki-e:platform-support, r=Noratrieb Fix "std" support status of some tier 3 targets rust-lang#127265 marked targets with empty "std" support status as no-std targets in target-spec metadata: > * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.) https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3 > The `std` column in the table below has the following meanings: > > * ✓ indicates the full standard library is available. > * \* indicates the target only supports [`no_std`] development. > * ? indicates the standard library support is unknown or a work-in-progress. > > [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata. The new status is set based on the following criteria: - Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl) - Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl taiki-e/rust-cross-toolchain@f3068b6), so I included them in the group below that means “work in progress” rather than in this group. - Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available. - Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported. r? Noratrieb cc ``@harmou01``

rustbot assigned Noratrieb Dec 4, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 4, 2024

Noratrieb reviewed Dec 4, 2024

View reviewed changes

Fix "std" support status of some tier 3 targets

76f9aa1

taiki-e force-pushed the platform-support branch from efd54b0 to 76f9aa1 Compare December 4, 2024 19:24

Mark all Linux/Android/BSD/Fuchsia as supporting "std" in target-spec…

e3638e2

… metadata

taiki-e force-pushed the platform-support branch from a481a36 to e3638e2 Compare December 5, 2024 01:49

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 5, 2024

fmease mentioned this pull request Dec 5, 2024

Rollup of 10 pull requests #133894

Closed

jhpratt mentioned this pull request Dec 5, 2024

Rollup of 6 pull requests #133905

Merged

bors merged commit 5dd102e into rust-lang:master Dec 5, 2024
6 checks passed

rustbot added this to the 1.85.0 milestone Dec 5, 2024

taiki-e deleted the platform-support branch December 6, 2024 01:24

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix "std" support status of some tier 3 targets #133867

Fix "std" support status of some tier 3 targets #133867

taiki-e commented Dec 4, 2024 •

edited

Loading

rustbot commented Dec 4, 2024

Noratrieb Dec 4, 2024

taiki-e Dec 4, 2024

taiki-e Dec 4, 2024 •

edited

Loading

Noratrieb Dec 4, 2024 •

edited

Loading

taiki-e Dec 5, 2024

Noratrieb commented Dec 5, 2024

bors commented Dec 5, 2024

Fix "std" support status of some tier 3 targets #133867

Fix "std" support status of some tier 3 targets #133867

Conversation

taiki-e commented Dec 4, 2024 • edited Loading

rustbot commented Dec 4, 2024

Noratrieb Dec 4, 2024

Choose a reason for hiding this comment

taiki-e Dec 4, 2024

Choose a reason for hiding this comment

taiki-e Dec 4, 2024 • edited Loading

Choose a reason for hiding this comment

Noratrieb Dec 4, 2024 • edited Loading

Choose a reason for hiding this comment

taiki-e Dec 5, 2024

Choose a reason for hiding this comment

Noratrieb commented Dec 5, 2024

bors commented Dec 5, 2024

taiki-e commented Dec 4, 2024 •

edited

Loading

taiki-e Dec 4, 2024 •

edited

Loading

Noratrieb Dec 4, 2024 •

edited

Loading