| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bump bootstrap compiler to 1.91 beta
https://forge.rust-lang.org/release/process.html#default-branch-bootstrap-update-tuesday
|
|
|
|
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
|
|
Explicitly note `&[SocketAddr]` impl of `ToSocketAddrs`
Although the examples below this list do imply that there's an impl of `ToSocketAddrs` for `&[SocketAddr]`, it's not actually noted in the list of default implementations.
|
|
unstably constify float mul_add methods
Tracking issue: rust-lang/rust#146724
r? `@tgross35`
|
|
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
|
|
Although the examples below this list do imply that there's an impl of
`ToSocketAddrs` for `&[SocketAddr]`, it's not actually noted in the list
of default implementations.
|
|
Fix infinite recursion in Path::eq with String
- Closes [after beta backport] rust-lang/rust#146940
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
library: std: sys: pal: uefi: Add some comments
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.
|
|
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>
|
|
#140368 Mutex/RwLock/ReentrantLock::data_ptr to be const fn
|
|
Fix uses of "adaptor"
These docs are in en_US, so "adapter" is the correct spelling (and indeed used in the next line.)
A second commit comes along for the ride to fix other instances in non-rustdoc comments.
|
|
Add panic=immediate-abort
MCP: https://github.com/rust-lang/compiler-team/issues/909
This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts.
In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`.
The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large.
`-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing.
The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature.
To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it.
I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
|
|
|
|
Mark float intrinsics with no preconditions as safe
Note: for ease of reviewing, the list of safe intrinsics is sorted in the first commit, and then safe intrinsics are added in the second commit.
All *recently added* float intrinsics have been correctly marked as safe to call due to the fact that they have no preconditions. This adds the remaining float intrinsics which are safe to call to the safe intrinsic list, and removes the unsafe blocks around their calls.
---
Side note: this may want a try run before being added to the queue, since I'm not sure if there's any tier-2 code that uses these intrinsics that might not be tested on the usual PR flow. We've already uncovered a few places in subtrees that do this, and it's worth double-checking before clogging up the queue.
|
|
|
|
All platforms define this structure the same way, so we can just put it in the `process` module directly.
|
|
|
|
|
|
Fix old typo in lang_start_internal comment
Noticed this when reading the rt cleanup code; the typo was introduced during a mass port of libstd to std in comments.
|
|
Stabilize `new_zeroed_alloc`
The corresponding `new_uninit` and `new_uninit_slice` functions were stabilized in rust-lang/rust#129401, but the zeroed counterparts were left for later out of a [desire](https://github.com/rust-lang/rust/issues/63291#issuecomment-2161039756) to stabilize only the minimal set. These functions are straightforward mirrors of the uninit functions and well-established. Since no blockers or design questions have surfaced in the past year, I think it's time to stabilize them.
Tracking issue: rust-lang/rust#129396
|
|
|
|
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`
|
|
initial implementation of the darwin_objc unstable feature
Tracking issue: https://github.com/rust-lang/rust/issues/145496
This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.
r? ```@tmandry```
try-job: `*apple*`
try-job: `x86_64-gnu-nopt`
|
|
These docs are in en_US, so "adapter" is the correct spelling
(and indeed used in the next line.)
|
|
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.
|
