Unresolved imports when building std without thread local

[xTachyon]

Doing the following:

rustc --print target-spec-json --target aarch64-apple-darwin -Z unstable-options > t.json
change is-builtin and has-thread-local to false in the json
cargo b -Z build-std=std,core,panic_unwind --target t.json

I expected to see this happen: it compiles

Instead, this happened:

error[E0432]: unresolved imports `crate::sys::thread_local::key::get`, `crate::sys::thread_local::key::set`, `crate::sys::thread_local::key::Key`, `crate::sys::thread_local::key::LazyKey`
 --> /Users/x/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/thread_local/os.rs:5:37
  |
5 | use crate::sys::thread_local::key::{get, set, Key, LazyKey};
  |                                     ^^^  ^^^  ^^^  ^^^^^^^ no `LazyKey` in `sys::thread_local::key`
  |                                     |    |    |
  |                                     |    |    no `Key` in `sys::thread_local::key`
  |                                     |    no `set` in `sys::thread_local::key`
  |                                     no `get` in `sys::thread_local::key`
  |
note: module `crate::collections::hash::set` exists but is inaccessible
 --> /Users/x/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/std/src/collections/hash/mod.rs:4:1
  |
4 | pub mod set;
  | ^^^^^^^^^^^^ not accessible

This used to work on nightly versions from last year.

Meta

rustc --version --verbose:

rustc 1.81.0-nightly (d9284afea 2024-07-14)
binary: rustc
commit-hash: d9284afea99e0969a0e692b9e9fd61ea4ba21366
commit-date: 2024-07-14
host: aarch64-apple-darwin
release: 1.81.0-nightly
LLVM version: 18.1.7

[GrigorenkoPV]

Same thing happens with ./x.py check std for aarch64-unknown-none{,-softfloat}

[bvanjoi]

similar with rust-lang/cargo#14889

[saethlin]

Same thing happens with ./x.py check std for aarch64-unknown-none{,-softfloat}

That's trying to build std for a target with no operating system, which doesn't make sense to me because std is primarily (or entirely?) for access to OS APIs. Why do you want to do this?

[GrigorenkoPV]

Same thing happens with ./x.py check std for aarch64-unknown-none{,-softfloat}

That's trying to build std for a target with no operating system, which doesn't make sense to me because std is primarily (or entirely?) for access to OS APIs. Why do you want to do this?

I was submitting a PR touching some platform-specific parts of std recently, so at some point I just ran through the list of all targets to make sure I did not break anything. And I remembered seeing this particular error on a couple of unsupported targets.

[jedbrown]

std is primarily (or entirely?) for access to OS APIs. Why do you want to do this?

std also has the floating point math functions, including powi, which doesn't even require a math library. FWIW, I was previously using -Zbuild-std --target=nvptx64-nvidia-cuda without trouble, and had been linking (at IR level) with libdevice.10.bc to resolve math symbols. This is admittedly an abuse of std, but if -Zbuild-std is deliberately unsupported on such targets, we should decide on a way to access math functions that the linker can resolve (because the alternative of libm has poor performance).