Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#143069 (Add fast-path for accessing the current thread id)
- rust-lang/rust#146518 (Improve the documentation around `ZERO_AR_DATE`)
- rust-lang/rust#146596 (Add a dummy codegen backend)
- rust-lang/rust#146617 (Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics)
- rust-lang/rust#146635 (cg_llvm: Stop using `as_c_char_ptr` for coverage-related bindings)
- rust-lang/rust#147184 (Fix the bevy implied bounds hack for the next solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Accessing the thread id is often used in profiling and debugging, as
well as some approaches for sound single-threaded access to data.
Currently the only way to access the thread id is by first obtaining a
handle to the current thread. While this is not exactly slow, it does
require an atomic inc-ref and dec-ref operation, as well as the
injection of `Thread`'s drop code into the caller.
This publicly exposes the existing fast-path for accessing the current
thread id.
Add `Path::has_trailing_sep` and related methods
Implements rust-lang/libs-team#335.
Tracking issue: rust-lang/rust#142503
Notable differences from ACP:
* `trim_trailing_sep` was added to `Path` since it felt reasonable to ensure that the inverse operation was available.
* Per suggestion of `@kennytm,` added `push_trailing_sep` and `pop_trailing_sep` to `PathBuf` in addition to `set_trailing_sep`.
This also updates some of the docs on various `Path` methods to use the term "trailing separator" instead of "trailing slash" for consistency.
std: implement `hostname`
Resolves https://github.com/rust-lang/libs-team/issues/330
Tracking issue: https://github.com/rust-lang/rust/issues/135142
This is based on rust-lang/rust#135141, but I've reimplemented the UNIX version, which now:
* uses `sysconf(_SC_HOST_NAME_MAX)` as an initial buffer length
* returns `OutOfMemory` if the `Vec` allocation fails
* retries the operation if it detects that the name returned by `gethostname` was truncated
Additionally, as part of the rebase, I had to move some WinSock abstractions (initialisation and error access) to `sys::pal` so that they can be accessed from `sys::net::hostname`.
CC ``@orowith2os`` (and thank you for your work!)
Skip stack overflow handler for panic=immediate-abort
std installs guard pages and a signal handler to ensure that stackoverflows 1) terminate abruptly and 2) print an nice message. Even for panic=immediate-abort, 1) is desirable, we don't want silent data corruption there. But 2) is completely unnecessary, as users deliberately *don't* want nice messages, they want minimum binary size.
Therefore, skip the entire guard signal handler setup, which saves a lot of bytes.
I tested this with a hello world binary using fat LTO, build-std, panic=immediate-abort, opt-level=s, strip=debuginfo.
`size` reports significant savings:
```
text data bss dec hex filename
15252 1032 104 16388 4004 tiny-before
6881 964 48 7893 1ed5 tiny-after2
```
`nm -U` goes from 71 to 56, getting rid of a bunch of stack overflow related symbols. The disk size goes from `31k` to `24k`.
The impact on the error message is minimal, as the message was already
missing.
before:
```
fish: Job 1, './tiny-so-before' terminated by signal SIGABRT (Abort)
```
after:
```
fish: Job 1, './tiny-so-after' terminated by signal SIGSEGV (Address boundary error)
```
I didn't test the Windows part, but it likely also has savings.
redox: switch to colon as path separator
We recently changed this in order to better comply with assumptions about Unix-like systems. The current PATH is set to `/usr/bin` with no separators in order to ease the transition.
std installs guard pages and a signal handler to ensure that stackoverflows 1) terminate abruptly and 2) print an nice message. Even for panic=immediate-abort, 1) is desirable, we don't want silent data corruption there. But 2) is completely unnecessary, as users deliberately *don't* want nice messages, they want minimum binary size.
Therefore, skip the entire guard signal handler setup, which saves a lot of bytes.
I tested this with a hello world binary using fat LTO, build-std, panic=immediate-abort, opt-level=s, strip=debuginfo.
`size` reports significant savings:
```
text data bss dec hex filename
15252 1032 104 16388 4004 tiny-before
6881 964 48 7893 1ed5 tiny-after2
```
`nm -U` goes from 71 to 56, getting rid of a bunch of stack overflow related symbols. The disk size goes from `31k` to `24k`.
The impact on the error message is minimal, as the message was already
missing.
before:
```
fish: Job 1, './tiny-so-before' terminated by signal SIGABRT (Abort)
```
after:
```
fish: Job 1, './tiny-so-after' terminated by signal SIGSEGV (Address boundary error)
```
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.
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.
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](c6c5bad11e/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.
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.
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>
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.
