| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
std::pal::unix::thread fetching min stack size on netbsd.
PTHREAD_STACK_MIN is not defined however sysconf/_SC_THREAD_STACK_MIN returns it as it can vary from arch to another.
|
|
Allow calling these functions without `unsafe` blocks in editions up
until 2021, but don't trigger the `unused_unsafe` lint for `unsafe`
blocks containing these functions.
Fixes #27970.
Fixes #90308.
CC #124866.
|
|
|
|
Less syscalls for the `copy_file_range` probe
If it's obvious from the actual syscall results themselves that the syscall is supported or unsupported, don't do an extra syscall with an invalid file descriptor.
CC #122052
|
|
PTHREAD_STACK_MIN is not defined however sysconf/_SC_THREAD_STACK_MIN
returns it as it can vary from arch to another.
|
|
use posix_memalign on almost all Unix targets
Seems nice to be able to use a single common codepath for all of them. :) The `libc` crate says this symbol exists for all Unix targets. I did locally do check-builds to ensure this still builds, but I can't really test more than that.
- For redox, I found indications posix_memalign really exists [here](https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/271)
- For esp-idf, I found indications [here](https://github.com/playable-tech/esp-idf/commit/c5b297a86f3d65081bc690e81ab53db47b18d31c)
- ~~For horizon and vita (these seem to be gaming console OSes? "Horizon OS" also has some hits for a Facebook product but that seems unrelated), they seem to be based on "newlib", where posix_memalign [seems to exist](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3ba2c39fb2a12cd7332ef16b1b3e3df994f7c6f5).~~ Turns out no, this 20-year-old standard POSIX function is unfortunately [not supported](https://github.com/rust-lang/rust/pull/125271#issuecomment-2119221419) here.
|
|
Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS
Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance).
The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute).
That we've been overly cautious here has also been noted by `@thomcc` in https://github.com/rust-lang/rust/pull/117910#issuecomment-1903372350.
r? `@workingjubilee`
`@rustbot` label O-apple
|
|
|
|
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
|
|
|
|
|
|
|
If we're comfortable using `_NSGetEnviron` from `crt_externs.h`, there shouldn't be an issue with using these either, and then we can merge with the macOS implementation.
This also fixes two test cases on Mac Catalyst:
- `tests/ui/command/command-argv0.rs`, maybe because `[[NSProcessInfo processInfo] arguments]` somehow converts the name of the first argument?
- `tests/ui/env-funky-keys.rs` since we no longer link to Foundation.
|
|
This should be slightly more correct, and matches the implementation in other programming languages:
- [Python's `os.environ`](https://github.com/python/cpython/blob/v3.12.3/Modules/posixmodule.c#L1562-L1566).
- [Swift's `Darwin.environ`](https://github.com/apple/swift-corelibs-foundation/blob/swift-5.10-RELEASE/CoreFoundation/Base.subproj/CFPlatform.c#L1811-L1812), though that library is bundled on the system, so they can change it if they want.
- [Dart/Flutter](https://github.com/dart-lang/sdk/blob/3.4.0/runtime/bin/platform_macos.cc#L205-L234), doesn't support environment variables on iOS.
- Node seems to not be entirely consistent with it:
- [`process.c`](https://github.com/nodejs/node/blob/v22.1.0/deps/uv/src/unix/process.c#L38).
- [`unix/core.c`](https://github.com/nodejs/node/blob/v22.1.0/deps/uv/src/unix/core.c#L59).
- [.NET/Xamarin](https://github.com/dotnet/runtime/blob/v8.0.5/src/native/libs/configure.cmake#L1099-L1106).
- [OpenJDK](https://github.com/openjdk/jdk/blob/jdk-23%2B22/src/java.base/unix/native/libjava/ProcessEnvironment_md.c#L31-L33).
|
|
avoid using aligned_alloc; posix_memalign is better-behaved
Also there's no reason why wasi should be different than all the other Unixes here.
|
|
|
|
std::alloc: use posix_memalign instead of memalign on solarish
`memalign` on Solarish requires the alignment to be at least the size of a pointer, which we did not honor. `posix_memalign` also requires that, but that code path already takes care of this requirement.
close GH-124787
|
|
simpler code path since small alignments are already taking care of.
close GH-124787
|
|
std::rand: adding solaris/illumos for getrandom support.
To help solarish support for miri https://https://github.com/rust-lang/miri/issues/3567
|
|
Convert instances of `target_os = "macos"` to `target_vendor = "apple"`
https://github.com/rust-lang/rust/pull/124491 migrated towards using `target_vendor = "apple"` more, as there's very little difference between iOS, tvOS, watchOS and visionOS. In that PR, I only did the changes where the standard library already had fixes for iOS, that I could confidently apply to the other targets.
However, there's actually also not that big of a gap between macOS and the aforementioned platforms - so in this PR, I've gone through a few of the instances of `target_os = "macos"` and replaced it with `target_vendor = "apple"` to improve support on those platforms, see the commits for details.
r? workingjubilee
CC `@thomcc` `@simlay` (do tell me if I should stop pinging you on these Apple PRs)
`@rustbot` label O-apple
|
|
std::net: Socket::new_raw now set to SO_NOSIGPIPE on freebsd.
|
|
To help solarish support for miri https://rust-lang/miri/issues/3567
|
|
This uses `libc::fcntl`, which, while not explicitly marked as available
in the headers, is already used by `File::sync_all` and `File::sync_data`
on these platforms, so should be fine to use here as well.
|
|
Tested in the iOS simulator with something like:
```
let mut buf = vec![0; c_int::MAX as usize - 1 + 2];
let read_bytes = f.read(&mut buf).unwrap();
```
|
|
Tested on an old MacBook and the iOS simulator.
|
|
Tested in the iOS simulator that the thread name is not set by default,
and that setting it improves the debugging experience in lldb / Xcode.
|
|
This fixes building `std` for targets like `mipsel-unknown-netbsd`.
If `c_long` is an `i64`, this conversion works with `Into`. But if it's
an `i32`, this failed to convert a `u32` to an `i32`.
|
|
Move thread parking to `sys::sync`
Part of #117276.
I'll leave the platform-specific API abstractions in `sys::pal`, as per the initial proposal. I'm not entirely sure whether we'll want to keep it that way, but that remains to be seen.
r? ``@ChrisDenton`` (if you have time)
|
|
Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`
In the stabilization [attempt](https://github.com/rust-lang/rust/pull/120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](https://github.com/rust-lang/rust/pull/120832#issuecomment-2007394609) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward.
So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature.
Another point was [also raised](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
|
|
|
|
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
|
|
|
|
Use `target_vendor = "apple"` instead of `target_os = "..."`
Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.
The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](https://github.com/rust-lang/rust/issues/100343), but not before an alternative (like `target_family = "apple"`) is available.
While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: https://github.com/rust-lang/rust/pull/124494
Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee
CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
|
|
Fuchsia doesn't support dirfd although we have a symbol stubbed for it.
|
|
|
|
`man posix_spawn` documents it to be able to return `ENOENT`, and there
should be nothing preventing this. Tested in the iOS simulator and on
Mac Catalyst.
|
|
|
|
Both `sysconf` and `_SC_NPROCESSORS_ONLN` is available on all Apple platforms.
|
|
|
|
|
|
Abort a process when FD ownership is violated
When an owned FD has already been closed before it's dropped that means something else touched an FD in ways it is not allowed to. At that point things can already be arbitrarily bad, e.g. clobbered mmaps. Recovery is not possible.
All we can do is hasten the fire.
Unlike the previous attempt in #124130 this shouldn't suffer from the possibility that FUSE filesystems can return arbitrary errors.
|
|
uses the same machinery as assert_unsafe_precondition
|
|
Unconditionally call `really_init` on GNU/Linux
This makes miri not diverge in behavior, it fixes running Rust linux-gnu binaries on musl with gcompat, it fixes dlopen edge-cases that cranelift somehow hits, etc.
Fixes #124126
thou hast gazed into this abyss with me:
r? ``@ChrisDenton``
|
|
This makes miri not diverge in behavior, it fixes running Rust linux-gnu
binaries on musl with gcompat, it fixes dlopen edge-cases that cranelift
somehow hits, etc.
|
|
|
|
As requested by @workingjubilee in
https://github.com/rust-lang/rust/pull/123928#discussion_r1564916743.
|
|
* Refactor apple OSs to use pwritev and preadv rather pwritev64 and preadv64
* Updated the comments for preadv and pwritev
|
|
When an EBADF happens then something else already touched an FD in ways it is not allowed to.
At that point things can already be arbitrarily bad, e.g. clobbered mmaps.
Recovery is not possible.
All we can do is hasten the fire.
|
|
Various visionOS fixes
A few small mistakes was introduced in https://github.com/rust-lang/rust/pull/121419, probably after the rename from `xros` to `visionos`. See the commits for details.
CC `@agg23`
Since you reviewed https://github.com/rust-lang/rust/pull/121419
r? davidtwco
|
