about summary refs log tree commit diff
path: root/library/std/src/sys
AgeCommit message (Collapse)AuthorLines
2023-10-15Make File::create work on Windows hidden filesChris Denton-6/+38
Previously it failed on Windows if the file had the `FILE_ATTRIBUTE_HIDDEN` attribute set. This was inconsistent with `OpenOptions::new().write(true).truncate(true)` which can truncate an existing hidden file.
2023-10-15Auto merge of #116683 - ChrisDenton:exists, r=Mark-Simulacrumbors-0/+21
Make `try_exists` return `Ok(true)` for Windows Unix Sockets This is a follow up to #109106 but for[ `fs::try_exists`](https://doc.rust-lang.org/std/fs/fn.try_exists.html), which doesn't need to get the metadata of a file (which can fail even if a file exists). `fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). This PR fixes it by checking for an error code that's returned when there's a failure to use a reparse point. ## Reparse points A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`. So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist on the filesystem so `try_exists` should report that as `Ok(true)`. r? libs
2023-10-14Fix broken build on ESP-IDF caused by #115108ivmarkov-4/+24
2023-10-13Auto merge of #115108 - ijackson:broken-wait-status, r=dtolnaybors-50/+144
Fix exit status / wait status on non-Unix cfg(unix) platforms Fixes #114593 Needs FCP due to behavioural changes (NB only on non-Unix `#[cfg(unix)]` platforms). Also, I think this is likely to break in CI. I have not been yet able to compile the new bits of `process_unsupported.rs`, although I have compiled the new module. I'd like some help from people familiar with eg emscripten and fuchsia (which are going to be affected, I think).
2023-10-13Make TCP connect() handle EINTR correctlyDenis Smirnov-9/+37
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-13Test that unix sockets exist on WindowsChris Denton-0/+14
2023-10-13Make try_exists return Ok(true) for Windows UDSChris Denton-0/+7
`fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). Fix this by checking for an error code that's returned when there's a failure to use a reparse point. A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`. So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist so `try_exists` should report that as `Ok(true)`.
2023-10-10On Windows make readdir error on the empty pathChris Denton-0/+8
2023-10-10Rewrite `read_encoded_pointer` conforming to strict provenanceniluxv-28/+69
* Entries in the callsite table now use a dedicated function for reading an offset rather than a pointer * `read_encoded_pointer` uses that new function for reading offsets when the "application" part of the encoding indicates an offset (relative to some pointer) * It now errors out on nonsensical "application" and "value encoding" combinations Inspired by @eddyb's comment on zulip about this: <https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/strict.20provenance.20in.20dwarf.3A.3Aeh/near/276197290>
2023-10-10Use pointers instead of `usize` addresses for landing padsniluxv-34/+41
This bring unwind and personality code more in line with strict-provenance
2023-10-09std: explain unconventional choice of let-else binding over while-let loopjoboet-0/+3
2023-10-09Support AIX in Rust standard libraryQiu Chaofan-3/+90
2023-10-07std: fix registering of Windows TLS destructorsjoboet-1/+4
2023-10-07Auto merge of #116501 - workingjubilee:rollup-fpzov6m, r=workingjubileebors-1/+1
Rollup of 4 pull requests Successful merges: - #116277 (dont call mir.post_mono_checks in codegen) - #116400 (Detect missing `=>` after match guard during parsing) - #116458 (Properly export function defined in test which uses global_asm!()) - #116500 (Add tvOS to target_os for register_dtor) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-06Add tvOS to target_os for register_dtorSebastian Imlay-1/+1
2023-10-06Use `io_error_more` on WASIShE3py-23/+92
2023-10-06Auto merge of #111595 - fortanix:raoul/waitqueue_clarifications, ↵bors-7/+19
r=workingjubilee `waitqueue` clarifications for SGX platform The documentation of `waitqueue` functions on the `x86_64-fortanix-unknown-sgx` platform is incorrect at some places and on others missing. This PR improves upon this. cc: `@jethrogb`
2023-10-06Windows: Support sub-millisecond sleepChris Denton-1/+88
Use `CreateWaitableTimerExW` with `CREATE_WAITABLE_TIMER_HIGH_RESOLUTION`. Does not work before Windows 10, version 1803 so in that case we fallback to using `Sleep`.
2023-10-06Auto merge of #116463 - ChrisDenton:nlibc, r=workingjubileebors-13/+18
Remove libc We don't use much libc on Windows and it seemed silly to keep if for the sake of [two well documented constants](https://learn.microsoft.com/en-us/cpp/c-runtime-library/exit-success-exit-failure?view=msvc-170).
2023-10-06Auto merge of #101150 - jethrogb:jb/cleanup-sgx-user-memory-copies, ↵bors-122/+85
r=workingjubilee Clean up SGX user memory copies Follow-up on #98126 and #100383 r? `@cuviper` cc `@raoulstrackx`
2023-10-06Remove libcChris Denton-13/+18
We don't use much libc on Windows.
2023-10-04Disable CFI for core and std CFI violationsRamon de C Valle-12/+31
Works around #115199 by temporarily disabling CFI for core and std CFI violations to allow the user rebuild and use both core and std with CFI enabled using the Cargo build-std feature.
2023-10-04std: abort instead of panicking if the global allocator uses TLSjoboet-4/+17
2023-10-03std: panic when the global allocator tries to register a TLS destructorjoboet-24/+20
2023-10-03Rollup merge of #116282 - rustaceanclub:master, r=davidtwcoMatthias Krüger-1/+1
Fix broken links The previous address is no longer available, replace it with the latest available one.
2023-10-02Rollup merge of #116289 - linkmauve:patch-1, r=the8472Tyler Mandry-0/+1
Add missing #[inline] on AsFd impl for sys::unix::fs::File This operation should be extremely cheap, at most the `mov` of the underlying file descriptor, but due to this missing `#[inline]` it is currently a function call.
2023-10-02Auto merge of #116207 - Ayush1325:uefi_stdio, r=Mark-Simulacrumbors-1/+162
Stdio support for UEFI - Uses Simple Text Output Protocol and Simple Text Input Protocol - Reading is done one character at a time - Writing is done with max 4096 characters # Quirks ## Output Newline - UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of `println` looks weird. - However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell `cat` command seems to work fine with just LF. ## Input Newline - `Stdin.read_line()` method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered. - Works fine with input redirection from file. CC `@dvdhrm`
2023-10-02Stdio for UEFIAyush Singh-1/+162
- Uses Simple Text Output Protocol and Simple Text Input Protocol - Reading is done one character at a time - Writing is done with max 4096 characters Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
2023-09-30Add missing #[inline] on AsFd impl for sys::unix::fs::Filelinkmauve-0/+1
This operation should be extremely cheap, at most the mov of the underlying file descriptor, but due to this missing #[inline] it is currently a function call.
2023-09-30Fix broken linkscui fliter-1/+1
Signed-off-by: cui fliter <imcusg@gmail.com>
2023-09-28time: use clock_gettime on macosTamir Duberstein-148/+44
Replace `mach_{absolute_time,timebase_info}` with `clock_gettime(CLOCK_REALTIME)` on: ``` all(target_os = "macos", not(target_arch = "aarch64")), target_os = "ios", target_os = "watchos", target_os = "tvos" ))] ``` `mach_{absolute_time,timebase_info}` were first used in https://github.com/time-rs/time/commit/cc367edd953e72756ed6f0980918795c11e469b1 which predated the introduction of `clock_gettime` support in macOS 10.12 Sierra which became the minimum supported version in 58bbca958d917a89124da248735926f86c59a149. Note that this change was made for aarch64 in 5008a317ce8e508c390ed12bff281f307313376e which predated 10.12 becoming the minimum supported version. The discussion took place in https://github.com/rust-lang/rust/issues/91417 and in particular https://github.com/rust-lang/rust/issues/91417#issuecomment-992151582 and https://github.com/rust-lang/rust/issues/91417#issuecomment-1033048064 are relevant.
2023-09-28time: use clock_gettime on macosTamir Duberstein-49/+35
Replace `gettimeofday` with `clock_gettime(CLOCK_REALTIME)` on: ``` all(target_os = "macos", not(target_arch = "aarch64")), target_os = "ios", target_os = "watchos", target_os = "tvos" ))] ``` `gettimeofday` was first used in https://github.com/time-rs/time/commit/cc367edd953e72756ed6f0980918795c11e469b1 which predated the introduction of `clock_gettime` support in macOS 10.12 Sierra which became the minimum supported version in 58bbca958d917a89124da248735926f86c59a149.
2023-09-28time: cfg(any(x)) is the same as cfg(x)Tamir Duberstein-2/+2
This was left over in c043a0e7d6f347f9b2c7f08c5b3a179470e0f0c5.
2023-09-28Auto merge of #114882 - ChrisDenton:riddle-me, r=dtolnaybors-121/+112
Update windows ffi bindings Bump `windows-bindgen` to version 0.51.1. This brings with it some changes to the generated FFI bindings, but little that affects the code. One change that does have more of an impact is `SOCKET` being `usize` instead of either `u64` or `u32` (as is used in std's public `SOCKET` type). However, it's now easy enough to abstract over that difference. Finally I added a few new bindings that are likely to be used in pending PRs, mostly to make sure they're ok with the new metadata. r? libs
2023-09-28Auto merge of #98704 - vthib:impl-from-raw-for-childstd-structs, r=dtolnaybors-2/+14
Implement From<OwnedFd/Handle> for ChildStdin/out/err object ## Summary Comments in `library/std/src/process.rs` ( https://github.com/rust-lang/rust/commit/ab08639e5950f5c8a42a2870c9636181308c3686 ) indicates that `ChildStdin`, `ChildStdout`, `ChildStderr` implements some traits that are not actually implemented: `FromRawFd`, `FromRawHandle`, and the `From<OwnedFd>/From<OwnedHandle>` from the io_safety feature. In this PR I implement `FromRawHandle` and `FromRawFd` for those 3 objects. ## Usecase I have a usecase where those implementations are basically needed. I want to customize in the `Command::spawn` API how the pipes for the parent/child communications are created (mainly to strengthen the security attributes on them). I can properly setup the pipes, and the "child" handles can be provided to `Child::spawn` easily using `Stdio::from_raw_handle`. However, there is no way to generate the `ChildStd*` objects from the raw handle of the created name pipe, which would be very useful to still expose the same API than in other OS (basically a `spawn(...) -> (Child, ChildStdin, ChildStdout, ChildSterr)`, where on windows this is customized), and to for example use `tokio::ChildStdin::from_std` afterwards. ## Questions * Are those impls OK to add? I have searched to see if those impls were missing on purpose, or if it was just never implemented because never needed. I haven't found any indication on why they couldn't be added, although the user clearly has to be very careful that the handle provided makes sense (i think, mainly that it is in overlapped mode for windows). * If this change is ok, adding the impls for the io_safety feature would probably be best, or should it be done in another PR? * I just copy-pasted the `#[stable(...)]` attributes, but the `since` value has to be updated, I'm not sure to which value.
2023-09-24Auto merge of #105861 - Ayush1325:uefi-std-minimial, r=workingjubileebors-1/+715
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-24Auto merge of #104385 - BlackHoleFox:apple-minimum-bumps, r=petrochenkovbors-3/+2
Raise minimum supported Apple OS versions This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (https://github.com/rust-lang/compiler-team/issues/556). As of this PR, rustc and the stdlib now support these versions as the baseline: - macOS: 10.12 Sierra - iOS: 10 - tvOS: 10 - watchOS: 5 (Unchanged) In addition to everything this breaks indirectly, these changes also erase the `armv7-apple-ios` target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing. [Per comment](https://github.com/rust-lang/compiler-team/issues/556#issuecomment-1297175073), this requires a FCP to merge. cc `@wesleywiser.`
2023-09-23Raise minimum supported iOS version to 10.0BlackHoleFox-1/+1
Drop the armv7-apple-ios target too because its no longer supported with the hardware iOS 10 requires.
2023-09-23Raise minimum supported macOS to 10.12BlackHoleFox-2/+1
2023-09-22Rebase to masterAyush Singh-26/+66
- Update Example - Add thread_parking to sys::uefi - Fix unsafe in unsafe errors - Improve docs - Improve os/exit - Some asserts - Switch back to atomics Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
2023-09-22Use RawOsError for UEFIAyush Singh-178/+261
Some changes from this commit will probably be converted to its own PR. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Fixes from PRAyush Singh-4/+6
- Some comment fixes. - Make some functions unsafe. - Make helpers module private. - Rebase on master - Update r-efi to v4.2.0 Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Add support for building `std::os::uefi` docsAyush Singh-14/+13
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Handle ExitBootServicesAyush Singh-16/+83
- Make BootServices unavailable if ExitBootServices event is signaled. - Use thread locals for SystemTable and ImageHandle Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Fixes from PRAyush Singh-32/+41
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-09-22Add Minimal Std implementation for UEFIAyush Singh-1/+515
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 #116038 - the8472:panic-on-sched_getaffinity-bug, r=cuviperMatthias Krüger-6/+19
Fall back to _SC_NPROCESSORS_ONLN if sched_getaffinity returns an empty mask Followup to #115946 A gentler fix for #115868, one that doesn't panic, [suggested on zulip](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202023-09-19/near/391942927) In that situation - on the buggy kernel versions - a zero-mask means no affinities have been set so `_SC_NPROCESSORS_ONLN` provides the right value.
2023-09-22Rollup merge of #114379 - RalfJung:command-removed-env-vars, r=m-ou-seMatthias Krüger-0/+17
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-27/+119
added support for GNU/Hurd adding support for i686-unknown-hurd-gnu
2023-09-21Fall back to _SC_NPROCESSORS_ONLN if sched_getaffinity returns an empty maskThe 8472-6/+19
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-07 10:15:10 +0000