Increase the reach of panic_immediate_abort
I wanted to use/abuse this recently as part of another project, and I was surprised how many panic-related things were left in my binaries if I built a large crate with the feature enabled along with LTO. These changes get all the panic-related symbols that I could find out of my set of locally installed Rust utilities.
Create `windows/api.rs` for safer FFI
FFI is inherently unsafe. For memory safety we need to assert that some contract is being upheld on both sides of the FFI, though of course we can only ever check our side. In Rust, `unsafe` blocks are used to assert safety and `// SAFETY` comments describing why it is safe. Currently in sys/windows we have a lot of this unsafety spread all over the place, with variations on the same unsafe patterns repeated. And because of the repitition and frequency, we're a bit lax with the safety comments.
This PR aims to fix this and to make FFI safety more auditable by creating an `api` module with the goal of centralising and consolidating this unsafety. It contains thin wrappers around the Windows API that make most functions safe to call or, if that's not possible, then at least safer. Note that its goal is *only* to address safety. It does not stray far from the Windows API and intentionally does not attempt to make higher lever wrappers around, for example, file handles. This is better left to the existing modules. The windows/api.rs file has a top level comment to help future contributors understand the intent of the module and the design decisions made.
I chose two functions as a first tentative step towards the above goal:
- [`GetLastError`](https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror) is trivially safe. There's no reason to wrap it in an `unsafe` block every time. So I simply created a safe `get_last_error` wrapper.
- [`SetFileInformationByHandle`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileinformationbyhandle) is more complex. It essentially takes a generic type but over a C API which necessitates some amount of ceremony. Rather than implementing similar unsafe patterns in multiple places, I provide a safe `set_file_information_by_handle` that takes a Rusty generic type and handles converting that to the form required by the C FFI.
r? libs
Hide internal methods from documentation
The two methods here are perma-unstable and only made public for technical reasons. There is no reason to show them in documentation.
`@rustbot` label +A-docs
Rollup of 6 pull requests
Successful merges:
- #114998 (feat(docs): add cargo-pgo to PGO documentation 📝)
- #116868 (Tweak suggestion span for outer attr and point at item following invalid inner attr)
- #117240 (Fix documentation typo in std::iter::Iterator::collect_into)
- #117241 (Stash and cancel cycle errors for auto trait leakage in opaques)
- #117262 (Create a new ConstantKind variant (ZeroSized) for StableMIR)
- #117266 (replace transmute by raw pointer cast)
r? `@ghost`
`@rustbot` modify labels: rollup
Validate `feature` and `since` values inside `#[stable(…)]`
Previously the string passed to `#[unstable(feature = "...")]` would be validated as an identifier, but not `#[stable(feature = "...")]`. In the standard library there were `stable` attributes containing the empty string, and kebab-case string, neither of which should be allowed.
Pre-existing validation of `unstable`:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![unstable(feature = "kebab-case", issue = "none")]
#[unstable(feature = "kebab-case", issue = "none")]
pub struct Struct;
```
```console
error[E0546]: 'feature' is not an identifier
--> src/lib.rs:5:1
|
5 | #![unstable(feature = "kebab-case", issue = "none")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
For an `unstable` attribute, the need for an identifier is obvious because the downstream code needs to write a `#![feature(...)]` attribute containing that identifier. `#![feature(kebab-case)]` is not valid syntax and `#![feature(kebab_case)]` would not work if that is not the name of the feature.
Having a valid identifier even in `stable` is less essential but still useful because it allows for informative diagnostic about the stabilization of a feature. Compare:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![stable(feature = "kebab-case", since = "1.0.0")]
#[stable(feature = "kebab-case", since = "1.0.0")]
pub struct Struct;
```
```rust
// src/main.rs
#![feature(kebab_case)]
use repro::Struct;
fn main() {}
```
```console
error[E0635]: unknown feature `kebab_case`
--> src/main.rs:3:12
|
3 | #![feature(kebab_case)]
| ^^^^^^^^^^
```
vs the situation if we correctly use `feature = "snake_case"` and `#![feature(snake_case)]`, as enforced by this PR:
```console
warning: the feature `snake_case` has been stable since 1.0.0 and no longer requires an attribute to enable
--> src/main.rs:3:12
|
3 | #![feature(snake_case)]
| ^^^^^^^^^^
|
= note: `#[warn(stable_features)]` on by default
```
Windows: Support sub-millisecond sleep
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`.
I've created a `WaitableTimer` type so it can one day be adapted to also support waiting to an absolute time (which has been talked about). Note though that it currently returns `Err(())` because we can't do anything with the errors other than fallback to the old `Sleep`. Feel free to tell me to do errors properly. It just didn't seem worth constructing an `io::Error` if we're never going to surface it to the user. And it *should* all be infallible anyway unless the OS is too old to support it.
Closes#43376
Remove Apple RNG fallbacks and simplify implementation
Now that we have [higher Apple platform requirements](https://github.com/rust-lang/rust/pull/104385), the RNG code can be simplified a lot. Since `getentropy` still doesn't look to be usable outside macOS this implementation:
- Removes any macOS fallback paths and unconditionally links to `getentropy`
- Minimizes the implementation for everything else (iOS, watchOS, etc).
`CCRandomGenerateBytes` was added in iOS 8 which means that we can use it now. It and `SecRandomCopyBytes` have the exact same functionality, but the former has a simpler API and no longer requires libstd to link to `Security.framework` for one function. Its also available in all the other target's SDKs.
Why care about `getentropy` then though on macOS? Well, its still much more performant. Benchmarking shows it runs at ~2x the speed of `CCRandomGenerateBytes`, which makes sense since it directly pulls from the kernel vs going through its own generator etc.
Semi-related to a previous, but reverted, attempt at improving this logic in https://github.com/rust-lang/rust/pull/101011
time: use clock_gettime on macos
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
cc367edd95
which predated the introduction of `clock_gettime` support in macOS
10.12 Sierra which became the minimum supported version in
58bbca958d.
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
cc367edd95
which predated the introduction of `clock_gettime` support in macOS
10.12 Sierra which became the minimum supported version in
58bbca958d.
Note that this change was made for aarch64 in
5008a317ce 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.
Rollup of 6 pull requests
Successful merges:
- #107159 (rand use getrandom for freebsd (available since 12.x))
- #116859 (Make `ty::print::Printer` take `&mut self` instead of `self`)
- #117046 (return unfixed len if pat has reported error)
- #117070 (rustdoc: wrap Type with Box instead of Generics)
- #117074 (Remove smir from triage and add me to stablemir)
- #117086 (Update .mailmap to promote my livename)
r? `@ghost`
`@rustbot` modify labels: rollup
report `unused_import` for empty reexports even it is pub
Fixes#116032
An easy fix. r? `@petrochenkov`
(Discovered this issue while reviewing #115993.)
On Windows make `read_dir` error on the empty path
This makes Windows consistent with other platforms. Note that this should not be taken to imply any decision on #114149 has been taken. However it was felt that while there is a lack of libs-api consensus, we should be consistent across platforms in the meantime.
This is a change in behaviour for Windows so will also need an fcp before merging.
r? libs-api
Specialize `Bytes<R>::next` when `R` is a `BufReader`.
This reduces the runtime for a simple program using `Bytes::next` to iterate through a file from 220ms to 70ms on my Linux box.
r? `@the8472`
Make TCP connect handle EINTR correctly
According to the [POSIX](https://pubs.opengroup.org/onlinepubs/009695399/functions/connect.html) 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. When the connection has been established asynchronously, select() and poll() shall indicate that the file descriptor for the socket is ready for writing.
The previous implementation differs from the recomendation: in a case of the EINTR we tried to reconnect in a loop and sometimes get EISCONN error (this problem was originally detected on MacOS).
1. More details about the problem in an [article](http://www.madore.org/~david/computers/connect-intr.html).
2. The original [issue](https://git.picodata.io/picodata/picodata/tarantool-module/-/issues/157).
Panic when the global allocator tries to register a TLS destructor
Using a `RefCell` avoids the undefined behaviour encountered in #116390 and reduces the amount of `unsafe` code in the codebase.
The bug report #27970 has existed for 8 years, the actual bug dates back
to Rust pre-1.0. I documented it since it's in the interest of the user
to be aware of it. The note can be removed once #27970 is fixed.
Updated libc and doc for Vita target
Doc changes:
- Updated Vita target readme. The recommended approach to build artifacts for the platform now is [cargo-vita](https://crates.io/crates/cargo-vita) which wraps all the convoluted steps previously described in a yaml for `cargo-make`
- Updated maintainer list for Vita target. (`@ZetaNumbers` `@pheki` please agree to be added to the list, `@amg98` please let us know if you're still planning on actively maintaining target support)
Code changes:
- ~Updated libc for rust-lang/libc#3284 and rust-lang/libc#3366~ (Already merged in #116527)
- In dupfd changed the flag same as for esp target, there is no CLOEXEC on Vita
- Enabled `new_pair` since we've implemented `socketpair` in Vita newlib
Inline `Bytes::next` and `Bytes::size_hint`.
This greatly increases its speed. On one small test program using `Bytes::next` to iterate over a large file, execution time dropped from ~330ms to ~220ms.
r? `@the8472`
impl Default for ExitCode
As suggested here
https://github.com/rust-lang/rust/pull/106425#issuecomment-1382952598
Needs FCP since this is an insta-stable impl.
Ideally we would have `impl From<ExitCode> for ExitStatus` and implement the default `ExitStatus` using that. That is sadly not so easy because of the various strange confusions about `ExitCode` (unix: exit status) vs `ExitStatus` (unix: wait status) in the not-really-unix platforms in `library//src/sys/unix/process`. I'll try to follow that up.
