std: Add Motor OS std library port
Motor OS was added as a no-std Tier-3 target in
[PR 146848](https://github.com/rust-lang/rust/pull/146848) as x86_64-unknown-motor.
This PR adds the std library for Motor OS.
While the PR may seem large, all it does is proxy
std pal calls to [moto-rt](https://crates.io/crates/moto-rt). Where there is some non-trivial
code (e.g. thread::spawn), it is quite similar, often
identical, to what other platforms do.
Update cargo
17 commits in 81c3f77a467359c8be6bc747dc93ec66a6e4ce11..367fd9f213750cd40317803dd0a5a3ce3f0c676d
2025-10-10 18:41:02 +0000 to 2025-10-15 15:01:32 +0000
- test: Don't look for a specfic ANSI color (rust-lang/cargo#16118)
- docs(guide): Clarify where to set config (rust-lang/cargo#16107)
- test(rustfix): re-enable disabled test due to unused variables (rust-lang/cargo#16114)
- Convert the "manifest has no things" warning to annotate_snippets. (rust-lang/cargo#16113)
- doc: make it clearer that `target.<cfg>.linker` is supported (rust-lang/cargo#16112)
- docs(guide): Cover feature-unification (rust-lang/cargo#16108)
- fix(gctx): types are unsupported not unknown (rust-lang/cargo#16109)
- fix(script): Tweak cargo script build-dir / target-dir (rust-lang/cargo#16086)
- docs(gctx): explain Value deserialization step-by-step (rust-lang/cargo#16105)
- docs(guide): Talk about removing unused features (rust-lang/cargo#16085)
- test(config): exercise unsupported TOML types (rust-lang/cargo#16100)
- docs(gctx): a bit more of how config deserialization works (rust-lang/cargo#16094)
- Refactor `Layout` into `BuildDirLayout` and `ArtifactDirLayout` (rust-lang/cargo#16092)
- Add alternative linker to the build performance guide (rust-lang/cargo#15991)
- refactor(gctx): extract error to a module (rust-lang/cargo#16091)
- fix: Fixed nightly tests failing due to unused_variables lint (rust-lang/cargo#16098)
- fix(script): Store cargo script lockfiles in build-dir (rust-lang/cargo#16087)
r? ghost
Restrict sysroot crate imports to those defined in this repo.
It's common to import dependencies from the sysroot via `extern crate` rather than use an explicit cargo dependency, when it's necessary to use the same dependency version as used by rustc itself. However, this is dangerous for crates.io crates, since rustc may not pull in the dependency on some targets, or may pull in multiple versions. In both cases, the `extern crate` fails to resolve.
To address this, re-export all such dependencies from the appropriate `rustc_*` crates, and use this alias from crates which would otherwise need to use `extern crate`.
See https://github.com/rust-lang/rust/pull/143492 for an example of the kind of issue that can occur.
It's common to import dependencies from the sysroot via `extern crate`
rather than use an explicit cargo dependency, when it's necessary to use
the same dependency version as used by rustc itself. However, this is
dangerous for crates.io crates, since rustc may not pull in the
dependency on some targets, or may pull in multiple versions. In both
cases, the `extern crate` fails to resolve.
To address this, re-export all such dependencies from the appropriate
`rustc_*` crates, and use this alias from crates which would otherwise
need to use `extern crate`.
Add vsx register support for ppc inline asm, and implement preserves_flag option
This should address the last(?) missing pieces of inline asm for ppc:
* Explicit VSX register support. ISA 2.06 (POWER7) added a 64x128b register overlay extending the fpr's to 128b, and unifies them with the vmx (altivec) registers. Implementations details within gcc/llvm percolate up, and require using the `x` template modifier. I have updated the inline asm to implicitly include this for vsx arguments which do not specify it. ~~Support for the gcc codegen backend is still a todo.~~
* Implement the `preserves_flags` option. All ABI's, and all ISAs store their flags in `cr`, and the carry bit lives inside `xer`. The other status registers hold sticky bits or control bits which do not affect branch instructions.
There is some interest in the e500 (powerpcspe) port. Architecturally, it has a very different FP ISA, and includes a simd extension called SPR (which is not IBM's cell SPE). Notably, it does not have altivec/fpr/vsx registers. It also has an SPE accumulator register which its ABI marks as volatile, but I am not sure if the compiler uses it.
Move computation of allocator shim contents to cg_ssa
In the future this should make it easier to use weak symbols for the allocator shim on platforms that properly support weak symbols. And it would allow reusing the allocator shim code for handling default implementations of the upcoming externally implementable items feature on platforms that don't properly support weak symbols.
In addition to make this possible, the alloc error handler is now handled in a way such that it is possible to avoid using the allocator shim when liballoc is compiled without `no_global_oom_handling` if you use `#[alloc_error_handler]`. Previously this was only possible if you avoided liballoc entirely or compiled it with `no_global_oom_handling`. You still need to avoid libstd and to define the symbol that indicates that avoiding the allocator shim is unstable.
std: improve handling of timed condition variable waits on macOS
Fixesrust-lang/rust#37440 (for good).
This fixes two issues with `Condvar::wait_timeout` on macOS:
Apple's implementation of `pthread_cond_timedwait` internally converts the absolute timeout to a relative one, measured in nanoseconds, but fails to consider overflow when doing so. This results in `wait_timeout` returning much earlier than anticipated when passed a duration that is slightly longer than `u64::MAX` nanoseconds (around 584 years). The existing clamping introduced by rust-lang/rust#42604 to address rust-lang/rust#37440 unfortunately used a maximum duration of 1000 years and thus still runs into the bug when run on older macOS versions (or with `PTHREAD_MUTEX_USE_ULOCK` set to a value other than "1"). See https://github.com/rust-lang/rust/issues/37440#issuecomment-3285958326 for context.
Reducing the maximum duration alone however would not be enough to make the implementation completely correct. As macOS does not support `pthread_condattr_setclock`, the deadline passed to `pthread_cond_timedwait` is measured against the wall-time clock. `std` currently calculates the deadline by retrieving the current time and adding the duration to that, only for macOS to convert the deadline back to a relative duration by [retrieving the current time itself](https://github.com/apple-oss-distributions/libpthread/blob/1ebf56b3a702df53213c2996e5e128a535d2577e/src/pthread_cond.c#L802-L819) (this conversion is performed before the aforementioned problematic one). Thus, if the wall-time clock is adjusted between the `std` lookup and the system lookup, the relative duration could have changed, possibly even to a value larger than $2^{64}\ \textrm{ns}$. Luckily however, macOS supports the non-standard, tongue-twisting `pthread_cond_timedwait_relative_np` function which avoids the wall-clock-time roundtrip by taking a relative timeout. Even apart from that, this function is perfectly suited for `std`'s purposes: it is public (albeit badly-documented) API, [available since macOS 10.4](https://github.com/apple-oss-distributions/libpthread/blob/1ebf56b3a702df53213c2996e5e128a535d2577e/include/pthread/pthread.h#L555-L559) (that's way below our minimum of 10.12) and completely resilient against wall-time changes as all timeouts are [measured against the monotonic clock](https://github.com/apple-oss-distributions/xnu/blob/e3723e1f17661b24996789d8afc084c0c3303b26/bsd/kern/sys_ulock.c#L741) inside the kernel.
Thus, this PR switches `Condvar::wait_timeout` to `pthread_cond_timedwait_relative_np`, making sure to clamp the duration to a maximum of $2^{64} - 1 \ \textrm{ns}$. I've added a miri shim as well, so the only thing missing is a definition of `pthread_cond_timedwait_relative_np` inside `libc`.
Where supported, VSX is a 64x128b register set which encompasses
both the floating point and vector registers.
In the type tests, xvsqrtdp is used as it is the only two-argument
vsx opcode supported by all targets on llvm. If you need to copy
a vsx register, the preferred way is "xxlor xt, xa, xa".
Hide vendoring and copyright in GHA group
These two steps are currently the most verbose steps in a dist-linux build, which makes it harder to find more interesting parts. Hide them in a group like most things.
For example, see https://github.com/rust-lang/rust/actions/runs/18462295959/job/52596384752
These two steps are currently the most verbose steps in a dist-linux
build, which makes it harder to find more interesting parts. Hide them
in a group like most things.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#144266 (Supress swapping lhs and rhs in equality suggestion in extern macro )
- rust-lang/rust#147471 (Assert that non-extended temporaries and `super let` bindings have scopes)
- rust-lang/rust#147533 (Renumber return local after state transform)
- rust-lang/rust#147566 (rewrite outlives placeholder constraints to outlives static when handling opaque types)
- rust-lang/rust#147613 (Make logging filters work again by moving EnvFilter into its own layer)
- rust-lang/rust#147615 (reduce calls to attr.span() in old doc attr parsing)
- rust-lang/rust#147636 (miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Generalize configuring LLD as the default linker in bootstrap
Reopen of https://github.com/rust-lang/rust/pull/147157, because apparently bors can't deal with it for some reason.
r? ``@ghost``
Matthias Krüger