Rollup of 7 pull requests
Successful merges:
- #116663 (Don't ICE when encountering unresolved regions in `fully_resolve`)
- #116761 (Fix podman detection in CI scripts)
- #116795 (Add `#[track_caller]` to `Option::unwrap_or_else`)
- #116829 (Make `#[repr(Rust)]` incompatible with other (non-modifier) representation hints like `C` and `simd`)
- #116883 (Change my name in mailmap)
- #116908 (Tweak wording of type errors involving type params)
- #116912 (Some renaming nits for `rustc_type_ir`)
r? `@ghost`
`@rustbot` modify labels: rollup
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.
document when atomic loads are guaranteed read-only
Based on this [discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Can.20.60Atomic*.3A.3Aload.60.20perform.20a.20write).
The values for x86 and x86_64 are complete guesswork on my side, and I have no clue what the values might be for other architectures. I hope we can get the right people to chime in to gather the required information. :)
I'll update Miri to respect these rules once we have more data.
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
Rollup of 6 pull requests
Successful merges:
- #116754 (coverage: Several small cleanups in `spans`)
- #116798 (Improve display of parallel jobs in rustdoc-gui tester script)
- #116800 (Fix implied outlives check for GAT in RPITIT)
- #116805 (Make `rustc_onunimplemented` export path agnostic)
- #116808 (Add myself to smir triage)
- #116811 (Preserve unicode escapes in format string literals when pretty-printing AST)
r? `@ghost`
`@rustbot` modify labels: rollup
This makes it so that all the matchers that match against paths use the
definition path instead of the export path. This removes all duplication
around `std`/`alloc`/`core`.
This is not necessarily optimal because we now depend on internal
implementation details like `core::ops::control_flow::ControlFlow`,
which is not very nice and probably not acceptable for a stable
`on_unimplemented`.
An alternative would be to just string-replace normalize away
`alloc`/`core` to `std` as a special case, keeping the export paths but
making it so that we're still fully standard library flavor agnostic.
Rollup of 3 pull requests
Successful merges:
- #115196 (Suggest adding `return` if the for semi which can coerce to the fn return type)
- #115955 (Stabilize `{IpAddr, Ipv6Addr}::to_canonical`)
- #116776 (Enable `review-requested` feature for rustbot)
r? `@ghost`
`@rustbot` modify labels: rollup
Stabilize `{IpAddr, Ipv6Addr}::to_canonical`
Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`.
Newly stable API:
```rust
impl IpAddr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
}
impl Ipv6Addr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
// Already stable, this makes it const stable under
// `const_ipv6_to_ipv4_mapped`
const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
```
These stabilize a subset of the following tracking issues:
- https://github.com/rust-lang/rust/issues/27709
- https://github.com/rust-lang/rust/issues/76205
Stabilization of all methods under the `ip` gate was attempted once at https://github.com/rust-lang/rust/pull/66584 then again at https://github.com/rust-lang/rust/pull/76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward.
I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in https://github.com/rust-lang/rust/pull/87708
cc implementor ``@the8472``
r? libs-api
``@rustbot`` label +T-libs-api +needs-fcp
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.
impl Not, Bit{And,Or}{,Assign} for IP addresses
ACP: rust-lang/libs-team#235
Note: since these are insta-stable, these require an FCP.
Implements, where `N` is either `4` or `6`:
```rust
impl Not for IpvNAddr
impl Not for &IpvNAddr
impl BitAnd<IpvNAddr> for IpvNAddr
impl BitAnd<&IpvNAddr> for IpvNAddr
impl BitAnd<IpvNAddr> for &IpvNAddr
impl BitAnd<&IpvNAddr> for &IpvNAddr
impl BitAndAssign<IpvNAddr> for IpvNAddr
impl BitAndAssign<&IpvNAddr> for IpvNAddr
impl BitOr<IpvNAddr> for IpvNAddr
impl BitOr<&IpvNAddr> for IpvNAddr
impl BitOr<IpvNAddr> for &IpvNAddr
impl BitOr<&IpvNAddr> for &IpvNAddr
impl BitOrAssign<IpvNAddr> for IpvNAddr
impl BitOrAssign<&IpvNAddr> for IpvNAddr
```
Implement sys::args for UEFI
- Uses `EFI_LOADED_IMAGE_PROTOCOL`, which is implemented for all loaded images.
Tested on qemu with OVMF
cc ``@nicholasbishop``
cc ``@dvdhrm``
Broaden the consequences of recursive TLS initialization
This PR updates the documentation of `LocalKey` to clearly disallow the behaviour described in [this comment](https://github.com/rust-lang/rust/issues/110897#issuecomment-1525738849). This allows using `OnceCell` for the lazy initialization of TLS variables, which panics on reentrant initialization instead of updating the value like TLS variables currently do.
``@rustbot`` label +T-libs-api
r? ``@m-ou-se``
error[E0711]: feature `process-exitcode-default` is declared stable since 1.74.0-beta.1, but was previously declared stable since 1.73.0
--> library/std/src/process.rs:1964:1
|
1964 | #[stable(feature = "process-exitcode-default", since = "CURRENT_RUSTC_VERSION")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Implement FusedIterator for DecodeUtf16 when the inner iterator does
I have just implemented an iterator that wraps `DecodeUtf16` and wanted to implement `FusedIterator` for my iterator when I noticed that `DecodeUtf16` currently doesn't implement `FusedIterator` at all.
A quick look at the code of `DecodeUtf16` revealed that `DecodeUtf16::next` only returns `None` when its inner iterator returns `None`:
3462f79e94/library/core/src/char/decode.rs (L45)
As a result, we can implement `FusedIterator` for `DecodeUtf16` when the inner iterator does.
I'm following the example of #96397 here and consider this change minor and non-controversial, which is why I haven't added an RFC. I have also added the required feature name (`"decode_utf16_fused_iterator"`), however without adding a chapter to the Rust Unstable book (same as #96397).
Make `try_exists` return `Ok(true)` for Windows Unix Sockets
This is a follow up to #109106 but for[ `fs::try_exists`](https://doc.rust-lang.org/std/fs/fn.try_exists.html), which doesn't need to get the metadata of a file (which can fail even if a file exists).
`fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). This PR fixes it by checking for an error code that's returned when there's a failure to use a reparse point.
## Reparse points
A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`.
So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist on the filesystem so `try_exists` should report that as `Ok(true)`.
r? libs
optimize zipping over array iterators
Fixes#115339 (somewhat)
the new assembly:
```asm
zip_arrays:
.cfi_startproc
vmovups (%rdx), %ymm0
leaq 32(%rsi), %rcx
vxorps %xmm1, %xmm1, %xmm1
vmovups %xmm1, -24(%rsp)
movq $0, -8(%rsp)
movq %rsi, -88(%rsp)
movq %rdi, %rax
movq %rcx, -80(%rsp)
vmovups %ymm0, -72(%rsp)
movq $0, -40(%rsp)
movq $32, -32(%rsp)
movq -24(%rsp), %rcx
vmovups (%rsi,%rcx), %ymm0
vorps -72(%rsp,%rcx), %ymm0, %ymm0
vmovups %ymm0, (%rsi,%rcx)
vmovups (%rsi), %ymm0
vmovups %ymm0, (%rdi)
vzeroupper
retq
```
This is still longer than the slice version given in the issue but at least it eliminates the terrible `vpextrb`/`orb` chain. I guess this is due to excessive memcpys again (haven't looked at the llvmir)?
The `TrustedLen` specialization is a drive-by change since I had to do something for the default impl anyway to be able to specialize the `TrustedRandomAccessNoCoerce` impl.
Fix broken build on ESP-IDF caused by #115108
`@ijackson` #115108 broke the build for ESP-IDF. I'm still checking whether this PR fixes everything - once I'm ready will remove the "Draft" status.
`@dtolnay` FYI
