summary refs log tree commit diff
path: root/library/std/src/sys_common
AgeCommit message (Collapse)AuthorLines
2024-04-11Beta revert "Use OS thread name by default"Chris Denton-3/+1
This reverts #121666 due to #123495 This has already been done on master but beta needs something that will backport cleanly. (cherry picked from commit 081ad8527d7b79e4761c497c12930e630de9a230)
2024-03-12std: move `Once` implementations to `sys`joboet-476/+0
2024-03-02Rollup merge of #121666 - ChrisDenton:thread-name, r=cuviperMatthias Krüger-1/+3
Use the OS thread name by default if `THREAD_INFO` has not been initialized Currently if `THREAD_INFO` hasn't been initialized then the name will be set to `None`. This PR changes it to use the OS thread name by default. This mostly affects foreign threads at the moment but we could expand this to make more use of the OS thread name in the future. Note: I've only implemented `Thread::get_name` for windows, linux and macos (and macos adjacent) targets. The rest just return `None`.
2024-03-01Auto merge of #114016 - krtab:delete_sys_memchr, r=workingjubileebors-138/+0
Delete architecture-specific memchr code in std::sys Currently all architecture-specific memchr code is only used in `std::io`. Most of the actual `memchr` capacity exposed to the user through the slice API is instead implemented in `core::slice::memchr`. Hence this commit deletes `memchr` from `std::sys[_common]` and replace calls to it by calls to `core::slice::memchr` functions. This deletes `(r)memchr` from the list of symbols linked to libc. The interest of putting architecture specific code back in core is linked to the discussion to be had in #113654
2024-02-27Use the OS thread name by default for the current threadChris Denton-1/+3
2024-02-24library: use `addr_of!`Pavel Grigorenko-5/+5
2024-02-21rename ptr::invalid -> ptr::without_provenanceRalf Jung-8/+8
also introduce ptr::dangling matching NonNull::dangling
2024-02-20Delete architecture-specific memchr code in std::sysArthur Carcano-138/+0
Currently all architecture-specific memchr code is only used in `std::io`. Most of the actual `memchr` capacity exposed to the user through the slice API is instead implemented in core::slice::memchr. Hence this commit deletes memchr from std::sys[_common] and replace calls to it by calls to core::slice::memchr functions. This deletes (r)memchr from the list of symbols linked to libc.
2024-02-18Auto merge of #121101 - GnomedDev:dyn-small-c-string, r=Nilstriebbors-1/+1
Reduce monomorphisation bloat in small_c_string This is a code path usually next to an FFI call, so taking the `dyn` slowdown for the 1159 llvm-line (fat lto, codegen-units 1, release build) drop in my testing program [t2fanrd](https://github.com/GnomedDev/t2fanrd) is worth it imo.
2024-02-18Dyn erase at call siteDavid Thomas-1/+1
2024-02-18Rollup merge of #118569 - blyxxyz:platform-os-str-slice, r=Mark-SimulacrumMatthias Krüger-4/+94
Move `OsStr::slice_encoded_bytes` validation to platform modules This delegates OS string slicing (`OsStr::slice_encoded_bytes`) validation to the underlying platform implementation. For now that results in increased performance and better error messages on Windows without any changes to semantics. In the future we may want to provide different semantics for different platforms. The existing implementation is still used on Unix and most other platforms and is now optimized a little better. Tracking issue: https://github.com/rust-lang/rust/issues/118485 cc `@epage,` `@BurntSushi`
2024-02-15Replace `NonZero::<_>::new` with `NonZero::new`.Markus Reiter-1/+1
2024-02-15Use generic `NonZero` internally.Markus Reiter-6/+7
2024-02-07Update testsr0cky-0/+2
2024-01-21Move `OsStr::slice_encoded_bytes` validation to platform modulesJan Verbeek-4/+94
On Windows and UEFI this improves performance and error messaging. On other platforms we optimize the fast path a bit more. This also prepares for later relaxing the checks on certain platforms.
2024-01-13std: once: use queue implementation on XousSean Cross-0/+1
Use the global queue implementation of Once when running on Xous. This gets us a thread-safe implementation, rather than using the non-threadsafe `unsupported` implementation. Signed-off-by: Sean Cross <sean@xobs.io>
2023-12-10Remove an allocation in min_stackAlex Saveau-1/+1
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2023-12-10remove redundant importssurechen-1/+0
detects redundant imports that can be eliminated. for #117772 : In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR.
2023-12-02std: Invert logic for inclusion of `sys_common::net`Alex Crichton-8/+8
The `library/std/src/sys_common/net.rs` module is intended to define common implementations of networking-related APIs across a variety of platforms that share similar APIs (e.g. Berkeley-style sockets and all). This module is not included for more fringe targets however such as UEFI or "unknown" targets to libstd (those classified as `restricted-std`). Previously the `sys_common/net.rs` file was set up such that an allow-list indicated it shouldn't be used. This commit inverts the logic to have an allow-list of when it should be used instead. The goal of this commit is to make it a bit easier to experiment with a new Rust target. Currently more esoteric targets are required to get an exception in this `cfg_if` block to use `crate::sys::net` such as for unsupported targets. With this inversion of logic only targets which actually support networking will be listed, where most of those are lumped under `cfg(unix)`. Given that this change is likely to cause some breakage for some target by accident I've attempted to be somewhat robust with this by following these steps to defining the new predicate for inverted logic. 1. Take all supported targets and filter out all `cfg(unix)` ones as these should all support `sys_common/net.rs`. 2. Take remaining targets and filter out `cfg(windows)` ones. 3. The remaining dozen-or-so targets were all audited by hand. Mostly this included `target_os = "hermit"` and `target_os = "solid_asp3"` which required an allow-list entry, but remaining targets were all already excluded (didn't use `sys_common/net.rs` so they were left out. If this causes breakage it should be relatively easy to fix and I'd be happy to follow-up with any PRs necessary.
2023-11-19Auto merge of #117895 - mzohreva:mz/fix-sgx-backtrace, r=Mark-Simulacrumbors-0/+12
Adjust frame IP in backtraces relative to image base for SGX target This is followup to https://github.com/rust-lang/backtrace-rs/pull/566. The backtraces printed by `panic!` or generated by `std::backtrace::Backtrace` in SGX target are not usable. The frame addresses need to be relative to image base address so they can be used for symbol resolution. Here's an example panic backtrace generated before this change: ``` $ cargo r --target x86_64-fortanix-unknown-sgx ... stack backtrace: 0: 0x7f8fe401d3a5 - <unknown> 1: 0x7f8fe4034780 - <unknown> 2: 0x7f8fe401c5a3 - <unknown> 3: 0x7f8fe401d1f5 - <unknown> 4: 0x7f8fe401e6f6 - <unknown> ``` Here's the same panic after this change: ``` $ cargo +stage1 r --target x86_64-fortanix-unknown-sgx stack backtrace: 0: 0x198bf - <unknown> 1: 0x3d181 - <unknown> 2: 0x26164 - <unknown> 3: 0x19705 - <unknown> 4: 0x1ef36 - <unknown> ``` cc `@jethrogb` and `@workingjubilee`
2023-11-17Use ptr::invalid_mut for SGX image baseMohsen Zohrevandi-1/+1
2023-11-15Re-format code with new rustfmtMark Rousskov-1/+2
2023-11-14Move SGX-specific image base logic to sys_commonMohsen Zohrevandi-5/+12
2023-11-14Adjust frame IP in backtraces relative to image base for SGX targetMohsen Zohrevandi-0/+5
2023-10-19Auto merge of #116132 - darthunix:connect_poll, r=cuviperbors-3/+1
Make TCP connect handle EINTR correctly According to the [POSIX](https://pubs.opengroup.org/onlinepubs/009695399/functions/connect.html) standard, if connect() is interrupted by a signal that is caught while blocked waiting to establish a connection, connect() shall fail and set errno to EINTR, but the connection request shall not be aborted, and the connection shall be established asynchronously. When the connection has been established asynchronously, select() and poll() shall indicate that the file descriptor for the socket is ready for writing. The previous implementation differs from the recomendation: in a case of the EINTR we tried to reconnect in a loop and sometimes get EISCONN error (this problem was originally detected on MacOS). 1. More details about the problem in an [article](http://www.madore.org/~david/computers/connect-intr.html). 2. The original [issue](https://git.picodata.io/picodata/picodata/tarantool-module/-/issues/157).
2023-10-13Make TCP connect() handle EINTR correctlyDenis Smirnov-3/+1
According to the POSIX standard, if connect() is interrupted by a signal that is caught while blocked waiting to establish a connection, connect() shall fail and set errno to EINTR, but the connection request shall not be aborted, and the connection shall be established asynchronously. If asynchronous connection was successfully established after EINTR and before the next connection attempt, OS returns EISCONN that was handled as an error before. This behavior is fixed now and we handle it as success. The problem affects MacOS users: Linux doesn't return EISCONN in this case, Windows connect() can not be interrupted without an old-fashoin WSACancelBlockingCall function that is not used in the library. So current solution gives connect() as OS specific implementation.
2023-10-04std: abort instead of panicking if the global allocator uses TLSjoboet-1/+4
2023-10-03std: panic when the global allocator tries to register a TLS destructorjoboet-5/+9
2023-09-24Auto merge of #105861 - Ayush1325:uefi-std-minimial, r=workingjubileebors-0/+1
Add Minimal Std implementation for UEFI # Implemented modules: 1. alloc 2. os_str 3. env 4. math # Related Links Tracking Issue: https://github.com/rust-lang/rust/issues/100499 API Change Proposal: https://github.com/rust-lang/libs-team/issues/87 # Additional Information 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. The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Fixes from PRAyush Singh-1/+0
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Add Minimal Std implementation for UEFIAyush Singh-0/+2
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-22Rollup merge of #114379 - RalfJung:command-removed-env-vars, r=m-ou-seMatthias Krüger-0/+4
Command: also print removed env vars There is no real shell syntax for unsetting an env var so easily, so we have to make one up. But we already do that for showing the 'program' name so I hope that's okay here, too. No strong opinion on what that should look like, I went with `unset(VAR_NAME)` for now.
2023-09-21Auto merge of #115230 - Vtewari2311:mod-hurd-latest, r=b-naberbors-0/+1
added support for GNU/Hurd adding support for i686-unknown-hurd-gnu
2023-09-21added support for GNU/HurdSamuel Thibault-0/+1
2023-09-20Auto merge of #115753 - tgross35:threadinfo-refactor, r=thomccbors-16/+21
Refactor `thread_info` to remove the `RefCell` `thread_info` currently uses `RefCell`-based initialization. Refactor this to use `OnceCell` instead which is more performant and better suits the needs of one-time initialization. This is nobody's bottleneck but OnceCell checks are a single `cmp` vs. `RefCell<Option>` needing runtime logic
2023-09-11Refactor `thread_info` to remove the `RefCell`Trevor Gross-16/+21
`thread_info` currently uses `RefCell`-based initialization. Refactor this to use `OnceCell` instead which is more performant and better suits the needs of one-time initialization.
2023-08-24also print clearing the environment entirelyRalf Jung-0/+4
2023-08-22libstd: add xous to libstdSean Cross-0/+1
Add the `xous` target to libstd. Currently this defers everything to the `unsupported` target. Signed-off-by: Sean Cross <sean@xobs.io>
2023-08-18Auto merge of #114591 - joboet:thread_parking_ordering_fix, r=thomccbors-11/+6
Synchronize with all calls to `unpark` in id-based thread parker [The documentation for `thread::park`](https://doc.rust-lang.org/nightly/std/thread/fn.park.html#memory-ordering) guarantees that "park synchronizes-with all prior unpark operations". In the id-based thread parking implementation, this is not implemented correctly, as the state variable is reset with a simple store, so there will not be a *synchronizes-with* edge if an `unpark` happens just before the reset. This PR corrects this, replacing the load-check-reset sequence with a single `compare_exchange`.
2023-08-14std: add some missing repr(transparent)Ralf Jung-0/+2
2023-08-07std: synchronize with all calls to `unpark` in id-based thread parkerjoboet-11/+6
2023-07-29print omitted frames count for short backtrace modeyukang-0/+19
2023-07-24remove additional [allow(unused_unsafe)]James Dietz-1/+0
2023-07-07Allow limited access to `OsString` bytesEd Page-0/+15
This extends #109698 to allow no-cost conversion between `Vec<u8>` and `OsString` as suggested in feedback from `os_str_bytes` crate in #111544.
2023-06-21wip: Support Apple tvOS in libstdThom Chiovoloni-1/+1
2023-06-14Rollup merge of #98202 - aticu:impl_tryfrom_osstr_for_str, r=AmanieuMatthias Krüger-10/+5
Implement `TryFrom<&OsStr>` for `&str` Recently when trying to work with `&OsStr` I was surprised to find this `impl` missing. Since the `to_str` method already existed the actual implementation is fairly non-controversial, except for maybe the choice of the error type. I chose an opaque error here instead of something like `std::str::Utf8Error`, since that would already make a number of assumption about the underlying implementation of `OsStr`. As this is a trait implementation, it is insta-stable, if I'm not mistaken? Either way this will need an FCP. I chose "1.64.0" as the version, since this is unlikely to land before the beta cut-off. `@rustbot` modify labels: +T-libs-api API Change Proposal: rust-lang/rust#99031 (accepted)
2023-06-12Implement `TryFrom<&OsStr>` for `&str`aticu-10/+5
2023-03-27Allow access to `OsStr` bytesEd Page-1/+7
`OsStr` has historically kept its implementation details private out of concern for locking us into a specific encoding on Windows. This is an alternative to #95290 which proposed specifying the encoding on Windows. Instead, this only specifies that for cross-platform code, `OsStr`'s encoding is a superset of UTF-8 and defines rules for safely interacting with it At minimum, this can greatly simplify the `os_str_bytes` crate and every arg parser that interacts with `OsStr` directly (which is most of those that support invalid UTF-8).
2023-05-17Fix #107910, Shorten backtraces in ICEsyukang-5/+6
2023-05-03Rollup merge of #105695 - joboet:remove_generic_parker, r=m-ou-seManish Goregaokar-129/+1
Replace generic thread parker with explicit no-op parker With #98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation. ````@rustbot```` label +T-libs +T-libs-api +A-atomic r? rust-lang/libs
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 09:17:40 +0000