libstd: -Z build-std is now broken for Cortex-M targets

[japaric]

Steps to reproduce

Expected this to work with a recent nightly but it didn't.

$ rustup default nightly-2022-06-22
$ rustup component add rust-src
$ rustup component add thumbv7m-none-eabi

$ cargo new --lib foo
$ cd foo
$ echo '#![no_std]' > src/lib.rs

$ cargo build -Z build-std --target thumbv7m-none-eabi
(..)
error: `sys_common::condvar::Condvar::new` is not yet stable as a const fn
   --> /home/japaric/.rustup/toolchains/nightly-2022-06-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/condvar.rs:129:26
    |
129 |         Condvar { inner: sys::Condvar::new() }
    |                          ^^^^^^^^^^^^^^^^^^^
    |
    = help: const-stable functions can only call other const-stable functions

error: `sys_common::mutex::MovableMutex::new` is not yet stable as a const fn
   --> /home/japaric/.rustup/toolchains/nightly-2022-06-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/mutex.rs:220:20
    |
220 |             inner: sys::MovableMutex::new(),
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: const-stable functions can only call other const-stable functions

error: `sys_common::rwlock::MovableRwLock::new` is not yet stable as a const fn
   --> /home/japaric/.rustup/toolchains/nightly-2022-06-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/rwlock.rs:153:20
    |
153 |             inner: sys::MovableRwLock::new(),
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: const-stable functions can only call other const-stable functions

error: could not compile `std` due to 3 previous errors

The most recent PR that touched code related to those lines is #97791.

Retrying the above steps with an older nightly (nightly-2022-06-18) before #97791 was merged works fine.

---

I find a bit odd that -Z build-std re-compiles libstd for a no-std target; I presume it's recompiling it to recompile proc_macro for the host. (?)

What's more strange is that using --target=$HOST works fine with nightly-2022-06-22.

$ # same Cargo project as before
$ rustc -Vv | rg host
host: x86_64-unknown-linux-gnu

$ cargo build -Z build-std --target x86_64-unknown-linux-gnu && echo OK
   Compiling std
(..)
   Compiling proc_macro
(..)
OK

So I'm not sure why libstd fails to compile for the host with -Z build-std --target=thumbv7m-none-eabi but not with -Z build-std --target=$HOST

Meta

$ rustc -Vv
rustc 1.63.0-nightly (dc80ca78b 2022-06-21)
binary: rustc
commit-hash: dc80ca78b6ec2b6bba02560470347433bcd0bb3c
commit-date: 2022-06-21
host: x86_64-unknown-linux-gnu
release: 1.63.0-nightly
LLVM version: 14.0.5

Workaround

Using -Z build-std=core (or =alloc) with thumbv7m-none-eabi compiles fine.

[ChrisDenton]

I think this might be a duplicate of #98293?

[japaric]

seems related. they seem to be using x.py to build std for the uefi target (judging from the stage1 in the file path) whereas here I'm using -Z build-std for a cortex-m target. if the uefi target (I'm not familiar with it) is also a no-std target the root cause may be the same.

[Ayush1325]

The cause in my case (UEFI) seems to be that building restcited_std is broken now.

[japaric]

submitted a fix in PR #98457 (not sure it's the right fix however)

[wcampbell0x2a]

Any update on this? I'm seeing the same issue with cargo +nightly build --release -Zbuild-std --target thumbv7em-none-eabi