| Age | Commit message (Collapse) | Author | Lines |
|---|
|
resolve: Do not finalize shadowed bindings
I.e. do not mark them as used, or non-speculatively loaded, or similar.
Previously they were sometimes finalized during early resolution, causing issues like https://github.com/rust-lang/rust/pull/144793#issuecomment-3168108005.
|
|
std: fix warning in VEXos stdio module
Fixes building `std` on the `armv7a-vex-v5` target due to an unnecessarily mutable argument in `Stdin`.
This was a stupid oversight on my part towards the end of rust-lang/rust#145973's review process. Missed a warning and had a bad bootstrap config that didn't tell me about it when testing changes.
|
|
|
|
I.e. do not mark them as used, or non-speculative loaded, or similar.
Previously they were sometimes finalized during early resolution, causing issues like https://github.com/rust-lang/rust/pull/144793#issuecomment-3168108005.
|
|
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#145067 (RawVecInner: add missing `unsafe` to unsafe fns)
- rust-lang/rust#145277 (Do not materialise X in [X; 0] when X is unsizing a const)
- rust-lang/rust#145973 (Add `std` support for `armv7a-vex-v5`)
- rust-lang/rust#146667 (Add an attribute to check the number of lanes in a SIMD vector after monomorphization)
- rust-lang/rust#146735 (unstably constify float mul_add methods)
- rust-lang/rust#146737 (f16_f128: enable some more tests in Miri)
- rust-lang/rust#146766 (Add attributes for #[global_allocator] functions)
- rust-lang/rust#146905 (llvm: update remarks support on LLVM 22)
- rust-lang/rust#146982 (Remove erroneous normalization step in `tests/run-make/linker-warning`)
- rust-lang/rust#147005 (Small string formatting cleanup)
- rust-lang/rust#147007 (Explicitly note `&[SocketAddr]` impl of `ToSocketAddrs`)
- rust-lang/rust#147008 (bootstrap.py: Respect build.jobs while building bootstrap tool)
- rust-lang/rust#147013 (rustdoc: Fix documentation for `--doctest-build-arg`)
- rust-lang/rust#147015 (Use `LLVMDisposeTargetMachine`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `std` support for `armv7a-vex-v5`
This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang/rust#131530.
This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/).
## Background
VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841).
## SDK Linkage
VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang/rust#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options:
- [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script.
- [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps.
- [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions.
- Linking their own implementation or stubbing the functions required by libstd.
The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main).
## Future Work
This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially.
Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146556 (Fix duration_since panic on unix when std is built with integer overflow checks)
- rust-lang/rust#146679 (Clarify Display for error should not include source)
- rust-lang/rust#146753 (Improve the pretty print of UnstableFeature clause)
- rust-lang/rust#146894 (Improve derive suggestion of const param)
- rust-lang/rust#146950 (core: simplify `CStr::default()`)
- rust-lang/rust#146958 (Fix infinite recursion in Path::eq with String)
- rust-lang/rust#146971 (fix ICE in writeback due to bound regions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Co-authored-by: Lewis McClelland <lewis@lewismcclelland.me>
|
|
I seemed to have forgotten that since I am using GET_PROTOCOL attribute
for the std usecases, I did not need to close the protocols explicitly.
So adding these comments as a note to future self not to waste time on
the same thing again.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
All platforms define this structure the same way, so we can just put it in the `process` module directly.
|
|
Fix unsupported `std::sys::thread` after move
Fixes building std for any platform with an unsupported thread abstraction. This includes {aarch64,armv7,x86_64}-unknown-trusty and riscv32im-risc0-zkvm-elf, which explicitly include the unsupported module, and platforms with no PAL.
Bug fix for rust-lang/rust#145177 (std: move thread into sys).
Also fix the `std` build for xtensa, which I incidentally found while looking for an unsupported platform.
r? ``@joboet``
|
|
Fix and provide instructions for running test suite on Apple simulators
The following now works:
```sh
./x test --host='' --target aarch64-apple-ios-sim --skip tests/debuginfo
./x test --host='' --target aarch64-apple-tvos-sim --skip tests/debuginfo
./x test --host='' --target aarch64-apple-watchos-sim --skip tests/debuginfo
./x test --host='' --target aarch64-apple-visionos-sim --skip tests/debuginfo
```
I have documented the setup I used [in the `rustc-dev-guide`](https://rustc-dev-guide.rust-lang.org/tests/running.html#testing-on-emulators), it's fairly standard use of `remote-test-server` (with a small fix to library load paths which I've made in the first commit).
I first tried the somewhat simpler `target.aarch64-apple-ios-sim.runner = "xcrun simctl spawn $UDID"`, but that doesn't work as required libraries etc. also need to be copied to the device.
The debuginfo tests fail, I think because the debug info in `.dSYM` isn't available. I am yet unsure exactly how to fix this, either we need to copy that directory to the target as well, or we need to configure `lldb` somehow to read it from the host.
I decided to not add this to our CI, since I suspect we wouldn't gain much from it? Running on the simulator still uses the host Darwin kernel, it's basically just configured to run in another mode with more restricted permissions and different system libraries.
r? jieyouxu
CC ``@simlay,`` you're a lot more familiar with `xcrun simctl` than I.
|
|
The macro is now builtin.
|
|
Fixes building std for any platform with an unsupported thread
abstraction. This includes {aarch64,armv7,x86_64}-unknown-trusty and
riscv32im-risc0-zkvm-elf, which explicitly include the unsupported
module, and platforms with no PAL.
Bug fix for PR 145177 (std: move thread into sys).
|
|
std: Fix WASI implementation of `remove_dir_all`
This commit is a change to the WASI-specific implementation of the `std::fs::remove_dir_all` function. Specifically it changes how directory entries are read of a directory-being-deleted to specifically buffer them all into a `Vec` before actually proceeding to delete anything. This is necessary to fix an interaction with how the WASIp1 `fd_readdir` API works to have everything work out in the face of mutations while reading a directory.
The basic problem is that `fd_readdir`, the WASIp1 API for reading directories, is not a stateful read of a directory but instead a "seekable" read of a directory. Its `cookie` argument enables seeking anywhere within the directory at any time to read further entries. Native host implementations do not have this ability, however, which means that this seeking property must be achieved by re-reading the directory. The problem with this is that WASIp1 has under-specified semantics around what should happen if a directory is mutated between two calls to `fd_readdir`. In essence there's not really any possible implementation in hosts except to read the entire directory and support seeking through the already-read list. This implementation is not possible in the WASIp1-to-WASIp2 adapter that is primarily used to create components for the `wasm32-wasip2` target where it has constrained memory requirements and can't buffer up arbitrarily sized directories. There's some more detailed discussion at https://github.com/bytecodealliance/wasmtime/issues/11701#issuecomment-3299957213 as well.
The WASIp1 API definitions are effectively "dead" now at the standards level meaning that `fd_readdir` won't be changing nor will a replacement be coming. For the `wasm32-wasip2` target this will get fixed once filesystem APIs are updated to use WASIp2 directly instead of WASIp1, making this buffering unnecessary. In essence while this is a hack it's sort of the least invasive thing that works everywhere for now. I don't think this is viable to fix in hosts so guests compiled to wasm are going to have to work around it by not relying on any guarantees about what happens to a directory if it's mutated between reads.
|
|
std: simplify host lookup
The logic for splitting up a string into a hostname and port is currently duplicated across (nearly) all of the networking implementations in `sys`. Since it does not actually rely on any system internals, this PR moves it to the `ToSocketAddr` implementation for `&str`, making it easier to discover and maintain.
On the other hand, the `ToSocketAddr` implementation (or rather the `resolve_socket_addr` function) contained logic to overwrite the port on the socket addresses returned by `LookupHost`, even though `LookupHost` is already aware of the port and sets the port already on Xous. This PR thus removes this logic by moving the responsibility of setting the port to the system-specific `LookupHost` implementation.
As a consequence of these changes, there remains only one way of creating `LookupHost`, hence I've removed the `TryFrom` implementations in favour of a `lookup_host` function, mirroring other, public iterator-based features.
And finally, I've simplified the parsing logic responsible for recognising IP addresses passed to `<(&str, u16)>::to_socket_addrs()` by using the `FromStr` impl of `IpAddr` rather than duplicating the parsing for both IP versions.
|
|
|
|
|
|
This commit is a change to the WASI-specific implementation of the
`std::fs::remove_dir_all` function. Specifically it changes how
directory entries are read of a directory-being-deleted to specifically
buffer them all into a `Vec` before actually proceeding to delete
anything. This is necessary to fix an interaction with how the WASIp1
`fd_readdir` API works to have everything work out in the face of
mutations while reading a directory.
The basic problem is that `fd_readdir`, the WASIp1 API for reading
directories, is not a stateful read of a directory but instead a
"seekable" read of a directory. Its `cookie` argument enables seeking
anywhere within the directory at any time to read further entries.
Native host implementations do not have this ability, however, which
means that this seeking property must be achieved by re-reading the
directory. The problem with this is that WASIp1 has under-specified
semantics around what should happen if a directory is mutated between
two calls to `fd_readdir`. In essence there's not really any possible
implementation in hosts except to read the entire directory and support
seeking through the already-read list. This implementation is not
possible in the WASIp1-to-WASIp2 adapter that is primarily used to
create components for the `wasm32-wasip2` target where it has
constrained memory requirements and can't buffer up arbitrarily sized
directories.
The WASIp1 API definitions are effectively "dead" now at the standards
level meaning that `fd_readdir` won't be changing nor will a replacement
be coming. For the `wasm32-wasip2` target this will get fixed once
filesystem APIs are updated to use WASIp2 directly instead of WASIp1,
making this buffering unnecessary. In essence while this is a hack it's
sort of the least invasive thing that works everywhere for now. I don't
think this is viable to fix in hosts so guests compiled to wasm are
going to have to work around it by not relying on any guarantees about
what happens to a directory if it's mutated between reads.
|
|
Fix `env::ArgsOs` for zkVM
The zkVM implementation of `env::ArgsOs` incorrectly reports the full length even after having iterated. Instead, use a range approach which works out to be simpler. Also, implement more iterator methods like the other platforms in #139847.
cc `@flaub` `@jbruestle` `@SchmErik`
|
|
On FreeBSD, use readdir instead of readdir_r
readdir_r has the same problems on FreeBSD as it does on other platforms: it assumes a fixed NAME_MAX. And readdir has the same thread-safety guarantee as it does on other platforms: it's safe as long as only one thread tries to read from the directory stream at a given time.
Furthermore, readdir_r is likely to be removed for FreeBSD 16, so we should stop using it now.
|
|
readdir_r has the same problems on FreeBSD as it does on other
platforms: it assumes a fixed NAME_MAX. And readdir has the same
thread-safety guarantee as it does on other platforms: it's safe as long
as only one thread tries to read from the directory stream at a given
time.
Furthermore, readdir_r is likely to be removed for FreeBSD 16, so we
should stop using it now.
|
|
Revert "Constify SystemTime methods"
This reverts https://github.com/rust-lang/rust/pull/144519. The const-hacks introduces bugs, and they make the code harder to maintain. Let's wait until we can constify these functions without changing their implementation.
Fixes https://github.com/rust-lang/rust/issues/146228.
Closes https://github.com/rust-lang/rust/issues/144517 (since the feature is gone).
r? `@tgross35`
Cc `@clarfonthey`
|
|
|
|
This reverts commit 7ce620dd7c6fc3371290b40a1ea28146f0d37031.
The const-hacks introduces bugs, and they make the code harder to maintain.
Let's wait until we can constify these functions without changing their implementation.
|
|
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#144549 (match clang's `va_arg` assembly on arm targets)
- rust-lang/rust#145895 (thread parking: fix docs and examples)
- rust-lang/rust#146308 (support integer literals in `${concat()}`)
- rust-lang/rust#146323 (check before test for hardware capabilites in bits 32~63 of usize)
- rust-lang/rust#146332 (tidy: make behavior of extra-checks more uniform)
- rust-lang/rust#146374 (Update `browser-ui-test` version to `0.22.2`)
- rust-lang/rust#146413 (Improve suggestion in case a bare URL is surrounded by brackets)
- rust-lang/rust#146426 (Bump miow to 0.60.1)
- rust-lang/rust#146432 (Implement `Socket::take_error` for Hermit)
- rust-lang/rust#146433 (rwlock tests: fix miri macos test regression)
- rust-lang/rust#146435 (Change the default value of `gcc.download-ci-gcc` to `true`)
- rust-lang/rust#146439 (fix cfg for poison test macro)
- rust-lang/rust#146448 ([rustdoc] Correctly handle literal search on paths)
- rust-lang/rust#146449 (Fix `libgccjit` symlink when we build GCC locally)
- rust-lang/rust#146455 (test: remove an outdated normalization for rustc versions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Implement `Socket::take_error` for Hermit
This PR fixes an unused-imports compilation error introduced in 845311a065a5638c516ed96c73b09862b176b329 and implements `Socket::take_error` for Hermit.
Hermit's `Socket::take_error` implementation works exactly like the one for Unix.
r? joboet
|
|
thread parking: fix docs and examples
Fixes https://github.com/rust-lang/rust/issues/145816
r? ```@joboet```
Cc ```@m-ou-se``` ```@Amanieu```
|
|
std: optimize `dlsym!` macro and add a test for it
The `dlsym!` macro always ensures that the name string is nul-terminated, so there is no need to perform the check at runtime. Also, acquire loads are generally faster than a load and a barrier, so use them. This is only false in the case where the symbol is missing, but that shouldn't matter too much.
|
|
std: move `thread` into `sys`
Part of https://github.com/rust-lang/rust/issues/117276.
|
|
|
|
This fixes
```
error: unused import: `str`
--> library/std/src/sys/pal/hermit/os.rs:6:22
|
6 | use crate::{fmt, io, str};
| ^^^
|
= note: `-D unused-imports` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unused_imports)]`
```
This was caused by 845311a065a5638c516ed96c73b09862b176b329.
|
|
Fix `compare_against_sw_vers` test
The `saturating_sub` doesn't actually perform its intended since the version numbers are signed integers (which I changed in a later revision of https://github.com/rust-lang/rust/pull/138944).
Fixes the issue described in https://github.com/rust-lang/rust/pull/138944#issuecomment-3270662876.
r? tgross35
|
|
std: make address resolution weirdness local to SGX
Currently, the implementations of `TcpStream::connect` and its cousins take an `io::Result<&SocketAddr>` as argument, which is very weird, as most of them then `?`-try the result immediately to access the actual address. This weirdness is however necessitated by a peculiarity of the SGX networking implementation:
SGX doesn't support DNS resolution but rather accepts hostnames in the same place as socket addresses. So, to make e.g.
```rust
TcpStream::connect("example.com:80")`
```
work, the DNS lookup returns a special error (`NonIpSockAddr`) instead, which contains the hostname being looked up. When `.to_socket_addrs()` fails, the `each_addr` function used to select an address will pass the error to the inner `TcpStream::connect` implementation, which in SGX's case will inspect the error and try recover the hostname from it. If
that succeeds, it continues with the found hostname.
This is pretty obviously a terrible hack and leads to buggy code (for instance, when users use the result of `.to_socket_addrs()` in their own `ToSocketAddrs` implementation to select from a list of possible URLs, the only URL used will be that of the last item tried). Still, without changes to the SGX usercall ABI, it cannot be avoided.
Therefore, this PR aims to minimise the impact of that weirdness and remove it from all non-SGX platforms. The inner `TcpStream::connect`, et al. functions now receive the `ToSocketAddrs` type directly and call `each_addr` (which is moved to `sys::net::connection`) themselves. On SGX, the implementation uses a special `each_addr` which contains the whole pass-hostname-through-error hack.
As well as making the code cleaner, this also opens up the possibility of reusing newly created sockets even if a connection request fails – but I've left that for another PR.
CC `@raoulstrackx`
|
|
`dlsym` doesn't work for finding libc symbols on platforms like linux-musl, so the test will fail.
|
|
|
|
|
|
The symbols __isPlatformVersionAtLeast and __isOSVersionAtLeast.
This allows the user to link both compiler_rt and std.
|
|
|
|
|
|
|
|
feat(std): emulate flock for solaris via fcntl
Upstream Solaris flock emulation to libstd from cargo.
This is borrowed from
https://github.com/rust-lang/cargo/blob/3b379fcc541b39321a7758552d37e5e0cc4277b9/src/cargo/util/flock.rs#L502-L536 which was implemented by an Oracle employee.
The code has been in cargo since 2022-12.
Python's `fcntl.flock` emulates like this as well: https://github.com/python/cpython/blob/c919d02edecfe9d75fe374756fb8aa1db8d95f55/Modules/fcntlmodule.c#L337-L400
We did the same thing in
https://github.com/rust-lang/rust/blob/0d0f4eac8b98133e5da6d3604d86a8f3b5a67844/compiler/rustc_data_structures/src/flock/unix.rs#L13-L39
However, should we just always falls back to fcntl for all Unix, instead of "unsupported"?
try-job: `*-solaris`
|
|
Upstream Solaris flock emulation to libstd from cargo.
This is borrowed from
https://github.com/rust-lang/cargo/blob/3b379fcc541b39321a7758552d37e5e0cc4277b9/src/cargo/util/flock.rs#L502-L536
which was implemented by an Oracle employee.
The code has been in cargo since 2022-12.
Python's `fcntl.flock` emulates like this as well:
https://github.com/python/cpython/blob/c919d02edecfe9d75fe374756fb8aa1db8d95f55/Modules/fcntlmodule.c#L337-L400
We did the same thing in
https://github.com/rust-lang/rust/blob/0d0f4eac8b98133e5da6d3604d86a8f3b5a67844/compiler/rustc_data_structures/src/flock/unix.rs#L13-L39
|
|
Add socket extensions for cygwin
r? `@joboet`
* Abstract name uds addr
* quickack
* passcred
|
|
|
|
Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols
## Motivation
When Objective-C code uses ```@available(...)`,`` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer.
The workaround is to link `libclang_rt.osx.a`, see e.g. https://github.com/alexcrichton/curl-rust/issues/279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often).
For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see https://github.com/rust-lang/rust/pull/62592#issuecomment-510670657 and https://github.com/rust-lang/rust/pull/134275#issuecomment-2543067830.
It is also a blocker for [setting the correct minimum OS version in `cc-rs`](https://github.com/rust-lang/rust/issues/136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ```@available(macos`` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes).
(My super secret evil agenda is also to expose some variant of ```@available``` in Rust's `std` after https://github.com/rust-lang/rfcs/pull/3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier).
## Solution
Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes.
**This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise.
I originally proposed to implement this in `compiler-builtins`, see https://github.com/rust-lang/compiler-builtins/pull/794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that).
Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ```@available``` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`).
A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](https://github.com/llvm/llvm-project/issues/64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation).
## Testing
Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all.
Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations:
- macOS 14.7.3 on a Macbook Pro M2
- `aarch64-apple-darwin`
- `x86_64-apple-darwin` (under Rosetta)
- `aarch64-apple-ios-macabi`
- `x86_64-apple-ios-macabi` (under Rosetta)
- `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting)
- `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5)
- `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2)
- `aarch64-apple-tvos-sim` (in tvOS Simulator)
- `aarch64-apple-watchos-sim` (in watchOS Simulator)
- `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting)
- `aarch64-apple-visionos-sim` (in visionOS Simulator)
- macOS 15.3.1 VM
- `aarch64-apple-darwin`
- `aarch64-apple-ios-macabi`
- macOS 10.12.6 on an Intel Macbook from 2013
- `x86_64-apple-darwin`
- `i686-apple-darwin`
- `x86_64-apple-ios` (in iOS Simulator)
- iOS 9.3.6 on a 1st generation iPad Mini
- `armv7-apple-ios` with an older compiler
Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected.
I believe the only real omissions here would be:
- `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above).
- `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting.
But I don't have the hardware available to test those.
``@rustbot`` label O-apple A-linkage -T-compiler -A-meta -A-run-make
try-job: aarch64-apple
|
|
Allows users to link to Objective-C code using `@available(...)`.
|
|
std: Implement WASIp2-specific stdio routines
This commit is an extension of rust-lang/rust#145944 but applied to stdio specifically. The stdio routines are updated away from WASIp1 APIs to using WASIp2 APIs natively. The end goal is to eventually drop the dependency on WASIp1 APIs in the standard library entirely in favor of exclusively depending on WASIp2.
|
|
This commit is an extension of previous libstd support but applied to stdio
specifically. The stdio routines are updated away from WASIp1 APIs to using
WASIp2 APIs natively. The end goal is to eventually drop the dependency on
WASIp1 APIs in the standard library entirely in favor of exclusively depending
on WASIp2.
|
