Turn stdarch into a Josh subtree

[Kobzol]

In a similar vein as #141229, this PR makes the stdarch repository a Josh subtree (it was previously a submodule). The initial commit of stdarch upon this is based is b6e2249e388f520627544812649b77b0944e1a2e, which is the previous commit SHA of the stdarch submodule. The sync was performed according to https://hackmd.io/7pOuxnkdQDaL1Y1FQr65xg.

This was decided in rust-lang/stdarch#1655.

Test pull PR on my fork: Kobzol/stdarch#1
Test push PR on my fork: Kobzol#59

I plan to use the same Rust (miri-inspired) tooling that we use for rustc-dev-guide to enable pulls/pushes on stdarch.

Note that this repository currently doesn't have any stdarch-specific tests, so before that, the subtree should only be modified through this repository only when dealing with changes that contain "cyclical dependencies" between stdarch and rustc. The long term vision is to integrate stdarch into rust-lang/rust completely.

CC @Amanieu

try-job: aarch64-apple
try-job: aarch64-gnu
try-job: x86_64-msvc-*
try-job: x86_64-gnu
try-job: x86_64-gnu-aux

[RalfJung]

Thanks a lot! However, I feel like this should be approved by t-libs... maybe r? @Amanieu ?

Also it my be a good idea to wait for compiler-builtins having their first successful syncs in both directions to ensure there's no hidden pitfalls in the setup.

How hard would it be to add a smoke test that at least checks that the crates build by themselves (i.e., outside of libcore)? That should be feasible wrt CI time and should catch some of the obvious issues -- the lib.rs file is otherwise entirely unused on the rustc side.

[Kobzol]

Also it my be a good idea to wait for compiler-builtins having their first successful syncs in both directions to ensure there's no hidden pitfalls in the setup.

Definitely agreed.

How hard would it be to add a smoke test that at least checks that the crates build by themselves (i.e., outside of libcore)? That should be feasible wrt CI time and should catch some of the obvious issues -- the lib.rs file is otherwise entirely unused on the rustc side.

Yeah, I think we should do at least some smoke test. I guess that we could do it in bootstrap, I'll take a look.

[bors]

☔ The latest upstream changes (presumably #141229) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

This is going to conflict with #141964 which updates the submodule.

[Kobzol]

How hard would it be to add a smoke test that at least checks that the crates build by themselves (i.e., outside of libcore)? That should be feasible wrt CI time and should catch some of the obvious issues -- the lib.rs file is otherwise entirely unused on the rustc side.

Is it required to build them using the in-tree rustc? Or is it enough to use stage0/beta compiler? Is it enough to just run cargo build in library/stdarch as a smoke test?

[RalfJung]

Well, the goal is to avoid multi-PR transitions for things like renaming an intrinsic that stdarch uses. So ideally the in-tree rustc is the only one that we require to be able to build stdarch.

[Kobzol]

@bors2 try

[rust-bors]

⌛ Trying commit b644ddc with merge 171601d…

To cancel the try build, run the command @bors2 try cancel.

[rust-log-analyzer]

The job aarch64-gnu-llvm-19-1 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[TIMING] core::build_steps::test::RustdocJson { compiler: Compiler { stage: 2, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } -- 0.000
Skipping Set({test::src/tools/rust-installer}) because it is excluded
Testing stdarch stage1 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
    Updating crates.io index
error: the lock file /checkout/library/stdarch/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:51:07
  local time: Mon Jun  9 10:34:03 UTC 2025
  network time: Mon, 09 Jun 2025 10:34:04 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

[rust-bors]

💔 Test failed

• CI ❌

[Kobzol]

error: the lock file /checkout/library/stdarch/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.

Hmm. What to do about stdarchs lockfile? Should we always update it in the rustc repo? I wonder how this works for miri and other tools, it seems like it also has its own lockfile.

[RalfJung]

For Miri, we basically never change the lockfile in the rustc repo. I do manual cargo updates in the Miri repo every now and then.

[Kobzol]

Oh, nevermind, stdarch actually doesn't have a lockfile, that's what was causing the issue. Sorry! The same issue actually happens also for https://github.com/rust-lang/compiler-builtins, as it also misses a lockfile, and it also causes bootstrap problems.