about summary refs log tree commit diff
path: root/library/std/src/sys/mod.rs
AgeCommit message (Collapse)AuthorLines
2025-09-10std: move `thread` into `sys`joboet-0/+1
2025-09-05Add __isOSVersionAtLeast and __isPlatformVersionAtLeast symbolsMads Marquart-0/+1
Allows users to link to Objective-C code using `@available(...)`.
2025-08-16tidy now installs typos-cli as-needed via cargobinarycat-1/+1
2025-08-05Dynamically enable LSE for aarch64 rust provided intrinsicsPaul Murphy-0/+5
Create a private module to hold the bootstrap code needed enable LSE at startup on aarch64-*-linux-* targets when rust implements the intrinsics. This is a bit more heavyweight than compiler-rt's LSE initialization, but has the benefit of initializing the aarch64 cpu feature detection for other uses. Using the rust initialization code does use some atomic operations, that's OK. Mixing LSE and non-LSE operations should work while the update flag propagates.
2025-04-21Move `sys::pal::os::Env` into `sys::env`Thalia Archibald-0/+1
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are publicly exposed via `std::env`, their implementations are each self-contained. Keep them separate in `std::sys` and make a new module, `sys::env`, for `Env`.
2025-04-18Combine env consts into std::sys::env_constsThalia Archibald-0/+1
2025-04-12Move args into std::sysThalia Archibald-0/+1
2025-04-04Move fd into sysThalia Archibald-0/+1
2025-03-22std: move process implementations to `sys`joboet-0/+1
As per #117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
2025-03-09std: move stdio to `sys`joboet-0/+1
As per #117276, this moves the platform definitions of `Stdout` and friends into `sys`. This PR also unifies the UNIX and Hermit implementations and moves the `__rust_print_err` function needed by libunwind on SGX into the dedicated module for such helper functions.
2025-03-08Move fs into sysThalia Archibald-0/+1
2025-02-07std: move `io` module out of `pal`joboet-0/+1
2025-02-02std: move network code into `sys`joboet-0/+1
As per #117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support #135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules. I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
2024-09-25Revert Break into the debugger on panic (129019)Chris Denton-1/+0
2024-09-23std: implement the `random` featurejoboet-0/+1
Implements the ACP https://github.com/rust-lang/libs-team/issues/393.
2024-09-05Break into the debugger (if attached) on panics (Windows, macOS, Linux, FreeBSD)kromych-0/+1
The developer experience for panics is to provide the backtrace and exit the program. When running under debugger, that might be improved by breaking into the debugger once the code panics thus enabling the developer to examine the program state at the exact time when the code panicked. Let the developer catch the panic in the debugger if it is attached. If the debugger is not attached, nothing changes. Providing this feature inside the standard library facilitates better debugging experience. Validated under Windows, Linux, macOS 14.6, and FreeBSD 13.3..14.1.
2024-08-27std: move allocators to `sys`joboet-0/+1
2024-07-30Cleanup sys module to match house styleChris Denton-1/+0
2024-07-23Initial implementation of anonymous_pipeJiahao XU-0/+2
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com> Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com> Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
2024-07-14std: deny(unsafe_op_in_unsafe_fn) but allow sitesJubilee Young-0/+2
This provides a list of locations to hunt down issues in.
2024-07-07Move/change declaration of `mod exit_guard;`zachs18-1/+1
2024-07-05Move exit guard from sys::common::exit_guard to sys::exit_guard.Zachary S-0/+1
2024-06-16std: move `sys_common::backtrace` to `sys`joboet-0/+1
2024-05-24std: clean up the TLS implementationjoboet-2/+0
2024-03-12std: move `Once` implementations to `sys`joboet-1/+1
2024-02-28std: move thread local implementation to `sys`joboet-0/+3
2024-02-16std: move locks to `sys` on µITRONjoboet-0/+1
2024-02-08std: move path into `sys`joboet-0/+1
2024-01-22std: move cmath into `sys`joboet-1/+3
2024-01-15std: move OS String implementation into `sys`joboet-0/+1
2024-01-13std: move personality implementation out of PALjoboet-0/+2
2024-01-11std: begin moving platform support modules into `pal`joboet-124/+8
2023-12-07add teeos std impl袁浩-0/+3
Signed-off-by: 袁浩 <yuanhao34@huawei.com>
2023-09-22Use RawOsError for UEFIAyush Singh-0/+1
Some changes from this commit will probably be converted to its own PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Add Minimal Std implementation for UEFIAyush Singh-0/+3
Implemented modules: 1. alloc 2. os_str 3. env 4. math Tracking Issue: https://github.com/rust-lang/rust/issues/100499 API Change Proposal: https://github.com/rust-lang/libs-team/issues/87 This was originally part of https://github.com/rust-lang/rust/pull/100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from @dvdhrm, I have extracted a minimal std implementation to this PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-19Auto merge of #104101 - betrusted-io:xous-libstd-initial, r=bjorn3bors-0/+3
Add initial libstd support for Xous This patchset adds some minimal support to the tier-3 target `riscv32imac-unknown-xous-elf`. The following features are supported: * alloc * thread creation and joining * thread sleeping * thread_local * panic_abort * mutex * condvar * stdout Additionally, internal support for the various Xous primitives surrounding IPC have been added as part of the Xous FFI. These may be exposed as part of `std::os::xous::ffi` in the future, however for now they are not public. This represents the minimum viable product. A future patchset will add support for networking and filesystem support.
2023-09-03Move RawOsError defination to sysAyush Singh-0/+2
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
2023-08-22libstd: add xous to libstdSean Cross-0/+3
Add the `xous` target to libstd. Currently this defers everything to the `unsupported` target. Signed-off-by: Sean Cross <sean@xobs.io>
2023-07-10Auto merge of #108796 - devsnek:personality-pal-exception, r=workingjubileebors-0/+1
move personality to sys this moves `personality` to sys, removing another PAL exception
2023-07-09move personality to sysGus Caplan-0/+1
2023-07-09move pal cfgs in f32 and f64 to sysGus Caplan-0/+49
2023-05-09Don't force include Windows goop when documentingChris Denton-25/+0
2023-03-17reviewGus Caplan-2/+2
2023-03-17move default backtrace setting to sysGus Caplan-0/+9
2022-10-03Reduce CString allocations in std as much as possibleAlex Saveau-1/+1
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2021-11-10Use `target_family = "wasm"`Alex Crichton-1/+1
2021-11-10std: Get the standard library compiling for wasm64Alex Crichton-1/+1
This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = "wasm32"` to also account for `target_arch = "wasm64"` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled, enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size, but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.
2021-09-28Add SOLID targetsTomoaki Kawada-0/+3
SOLID[1] is an embedded development platform provided by Kyoto Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support for SOLID. # New Targets The following targets are added: - `aarch64-kmc-solid_asp3` - `armv7a-kmc-solid_asp3-eabi` - `armv7a-kmc-solid_asp3-eabihf` SOLID's target software system can be divided into two parts: an RTOS kernel, which is responsible for threading and synchronization, and Core Services, which provides filesystems, networking, and other things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems (more precisely, systems where only one processor core is allocated for SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is traditionally only specified at the source-code level, the ABI is unique to each implementation, which is why `asp3` is included in the target names. More targets could be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future. # C Compiler Although SOLID provides its own supported C/C++ build toolchain, GNU Arm Embedded Toolchain seems to work for the purpose of building Rust. # Unresolved Questions A μITRON4 kernel can support `Thread::unpark` natively, but it's not used by this commit's implementation because the underlying kernel feature is also used to implement `Condvar`, and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives. # Unsupported or Unimplemented Features Most features are implemented. The following features are not implemented due to the lack of native support: - `fs::File::{file_attr, truncate, duplicate, set_permissions}` - `fs::{symlink, link, canonicalize}` - Process creation - Command-line arguments Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however. ## Dynamic Linking Dynamic linking is not supported. The target platform supports dynamic linking, but enabling this in Rust causes several problems. - The linker invocation used to build the shared object of `std` is too long for the platform-provided linker to handle. - A linker script with specific requirements is required for the compiled shared object to be actually loadable. As such, we decided to disable dynamic linking for now. Regardless, the users can try to create shared objects by manually invoking the linker. ## Executable Building an executable is not supported as the notion of "executable files" isn't well-defined for these targets. [1] https://solid.kmckk.com/SOLID/ [2] http://ertl.jp/ITRON/SPEC/mitron4-e.html [3] https://en.wikipedia.org/wiki/ITRON_project [4] https://toppers.jp/
2021-05-03Allow documenting on `hermit`Christiaan Dirkx-1/+0
2021-05-03Move `std::sys::wasi::ext` to `std::os::wasi`Christiaan Dirkx-17/+0
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 11:13:02 +0000