Skip to content

[do not merge] Move std_detect into stdlib #143412

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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

Kobzol
Copy link
Member

@Kobzol Kobzol commented Jul 4, 2025

This PR moves the std_detect crate from stdarch to be a part of rust-lang/rust instead.

The first commit actually moves the whole directory from the stdarch Josh subtree, so that git blame history is kept intact. Then I had to make a few changes to appease tidy.

The most complex thing here is porting the tests. We can't have std_detect both in r-l/r and stdarch, because they could get desynchronized, so we have to perform the move more or less "atomically", which means that we also have to port all the existing std_detect tests from the stdarch repository.

The stdarch repo runs the following std_detect tests:

Build

The build-std-detect.sh script (https://github.com/rust-lang/stdarch/blob/e2b6512aed87df45294ae680181eeef7a802cd95/ci/build-std-detect.sh) builds std_detect using the nightly compiler for several targets. This will be subsumed by normal x build library on our Tier 1/2 targets. However, the stdarch repository also tests the following targets:

  • aarch64-unknown-freebsd
  • armv6-unknown-freebsd
  • powerpc-unknown-freebsd
  • powerpc64-unknown-freebsd
  • aarch64-unknown-openbsd

Which we don't build/test on our CI currently. I think we have mostly two options here:

  1. Ignore these targets
  2. Create a special CI job that will build stage 1 rustc and then cross-compile std (or just the std_detect crate?) for these targets.

Documentation

The dox.sh script (https://github.com/rust-lang/stdarch/blob/3fec5adcd52a815f227805d4959a25b6402c7fd5/ci/dox.sh) builds and documents std_detect for several targets. All of them are Tier 2/we have dist- jobs for them, so I think that we can just skip this and let our normal CI subsume it?

Tests

The run.sh script (https://github.com/rust-lang/stdarch/blob/1b201cec2cca7465602a65ed6ae60517224b15f3/ci/run.sh) runs cargo test on std_detect with a bunch of variations of feature flags. This will be subsumed by x test library in our CI. The only problem is that stdarch runs these tests for a ludicrous number of targets:

        - tuple: i686-unknown-linux-gnu
        - tuple: x86_64-unknown-linux-gnu
        - tuple: arm-unknown-linux-gnueabihf
        - tuple: armv7-unknown-linux-gnueabihf
        - tuple: aarch64-unknown-linux-gnu
        - tuple: aarch64_be-unknown-linux-gnu
        - tuple: riscv32gc-unknown-linux-gnu
        - tuple: riscv64gc-unknown-linux-gnu
        - tuple: powerpc-unknown-linux-gnu
        - tuple: powerpc64-unknown-linux-gnu
        - tuple: powerpc64le-unknown-linux-gnu
        - tuple: s390x-unknown-linux-gnu
        - tuple: i586-unknown-linux-gnu
        - tuple: nvptx64-nvidia-cuda
        - tuple: thumbv6m-none-eabi
        - tuple: thumbv7m-none-eabi
        - tuple: thumbv7em-none-eabi
        - tuple: thumbv7em-none-eabihf
        - tuple: loongarch64-unknown-linux-gnu
        - tuple: wasm32-wasip1
        - tuple: x86_64-apple-darwin
        - tuple: x86_64-apple-ios-macabi
        - tuple: aarch64-apple-darwin
        - tuple: aarch64-apple-ios-macabi
        - tuple: x86_64-pc-windows-msvc
        - tuple: i686-pc-windows-msvc
        - tuple: aarch64-pc-windows-msvc
        - tuple: x86_64-pc-windows-gnu
        - tuple: aarch64-unknown-linux-gnu
        - tuple: aarch64_be-unknown-linux-gnu
        - tuple: armv7-unknown-linux-gnueabihf
        - tuple: loongarch64-unknown-linux-gnu
        - tuple: powerpc-unknown-linux-gnu
        - tuple: powerpc64-unknown-linux-gnu
        - tuple: powerpc64le-unknown-linux-gnu
        - tuple: riscv32gc-unknown-linux-gnu
        - tuple: riscv64gc-unknown-linux-gnu
        - tuple: s390x-unknown-linux-gnu
        - tuple: x86_64-unknown-linux-gnu
        - tuple: aarch64-apple-darwin
        - tuple: aarch64-apple-ios-macabi

We definitely do not run tests for all of these targets on our CI. So maybe include them into the special job that will cross-compile std_detect for Free/OpenBSD?

r? @ghost

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Jul 4, 2025
@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added A-tidy Area: The tidy tool T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jul 4, 2025
@rust-log-analyzer

This comment has been minimized.

@Kobzol Kobzol force-pushed the std-detect-in-stdlib branch from 9086668 to 277837d Compare July 4, 2025 13:25
@Kobzol Kobzol marked this pull request as ready for review July 8, 2025 08:45
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 8, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 8, 2025

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

There are changes to the tidy tool.

cc @jieyouxu

@Kobzol Kobzol changed the title Move std_detect into stdlib [do not merge] Move std_detect into stdlib Jul 8, 2025
@Kobzol
Copy link
Member Author

Kobzol commented Jul 8, 2025

This is not yet ready for review, but it will need some input from stdarch maintainers regarding the test changes, as they have to happen in this PR, otherwise we either lose testing for std_detect for some time, or we will have two duplicated sources for std_detect, neither is great. Not sure who to ping exactly about the CI changes though.

CC @rust-lang/libs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tidy Area: The tidy tool S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants