Merge subtree update for toolchain nightly-2025-04-23 #340
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Miri subtree update r? `@ghost`
`io::Take`: avoid new `BorrowedBuf` creation in some case If `self.limit == buf.capacity()`, doing the whole `BorrowedBuf` dance is not necessary.
Co-authored-by: Daniel Henry-Mantilla <[email protected]>
…ze, r=alexcrichton wasm: increase default thread stack size to 1 MB The default stack size for the [main thread is 1 MB as specified by linker options](https://github.com/rust-lang/rust/blob/38cf49dde8a5b0b284bb6dffd423d223c9f8f7a3/compiler/rustc_target/src/spec/base/wasm.rs#L14). However, the default stack size for threads was only 64 kB. This is surprisingly small and thus we increase it to 1 MB to match the main thread.
…, r=ibraheemdev Change the syntax of the internal `weak!` macro Change the syntax to include parameter names and a trailing semicolon. Motivation: - Mirror the `syscall!` macro. - Allow rustfmt to format it (when wrapped in parentheses, and when not inside `cfg_if!`). - For better documentation (having the parameter names available in the source code is a bit nicer). - Allow a future improvement to this macro where we can sometimes use the symbol directly when it's statically known to be available (and thus need the parameter names to be available), see rust-lang#136868. r? libs
Add more tests for pin!(). This adds the tests suggested by `@danielhenrymantilla` in this comment: rust-lang#138717 (comment) by
…nieu Implement `alloc::sync::UniqueArc` This implements the `alloc::sync::UniqueArc` part of rust-lang#112566.
stabilize const_cell
``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval`` I see no reason to wait any longer, so I propose we stabilize the use of `Cell` in `const fn` -- specifically the APIs listed here:
```rust
// core::cell
impl<T> Cell<T> {
pub const fn replace(&self, val: T) -> T;
}
impl<T: Copy> Cell<T> {
pub const fn get(&self) -> T;
}
impl<T: ?Sized> Cell<T> {
pub const fn get_mut(&mut self) -> &mut T;
pub const fn from_mut(t: &mut T) -> &Cell<T>;
}
impl<T> Cell<[T]> {
pub const fn as_slice_of_cells(&self) -> &[Cell<T>];
}
```
Unfortunately, `set` cannot be made `const fn` yet as it drops the old contents.
Fixes rust-lang#131283
…boet Start using `with_native_path` in `std::sys::fs` Ideally, each platform should use their own native path type internally. This will, for example, allow passing a `CStr` directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated C string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this PR does some minimal refactoring which should help progress towards that goal. The changes are Unix-only and even then I avoided functions that require more changes so that this PR is just moving things around. r? joboet
std: deduplicate `errno` accesses By marking `__errno_location` as `#[ffi_const]` and `std::sys::os::errno` as `#[inline]`, this PR allows merging multiple calls to `io::Error::last_os_error()` into one.
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#137928 (stabilize const_cell) - rust-lang#138431 (Fix `uclibc` LLVM target triples) - rust-lang#138832 (Start using `with_native_path` in `std::sys::fs`) - rust-lang#139081 (std: deduplicate `errno` accesses) - rust-lang#139100 (compiletest: Support matching diagnostics on lines below) - rust-lang#139105 (`BackendRepr::is_signed`: comment why this may panics) - rust-lang#139106 (Mark .pp files as Rust) r? `@ghost` `@rustbot` modify labels: rollup
Instead of calling new(), we can just use a struct expression directly.
Before:
Placeholder::new(…, …, …, …)
After:
Placeholder {
position: …,
flags: …,
width: …,
precision: …,
}
Remove unsafe `split_at_unchecked` and `split_at_mut_unchecked` in some slice `split_first_chunk`/`split_last_chunk` methods. Replace those calls with the safe `split_at` and `split_at_checked` where applicable. Add codegen tests to check for no panics when calculating the last chunk index using `checked_sub` and `split_at`
…ark-Simulacrum
Simplify expansion for format_args!().
Instead of calling `Placeholder::new()`, we can just use a struct expression directly.
Before:
```rust
Placeholder::new(…, …, …, …)
```
After:
```rust
Placeholder {
position: …,
flags: …,
width: …,
precision: …,
}
```
(I originally avoided the struct expression, because `Placeholder` had a lot of fields. But now that rust-lang#136974 is merged, it only has four fields left.)
This will make the `fmt` argument to `fmt::Arguments::new_v1_formatted()` a candidate for const promotion, which is important if we ever hope to tackle rust-lang#92698 (It doesn't change anything yet though, because the `args` argument to `fmt::Arguments::new_v1_formatted()` is not const-promotable.)
Switch some rustc_on_unimplemented uses to diagnostic::on_unimplemented The use on the SliceIndex impl appears unreachable, there is no mention of "vector indices" in any test output and I could not get it to show up in error messages.
Rollup of 5 pull requests Successful merges: - rust-lang#139044 (bootstrap: Avoid cloning `change-id` list) - rust-lang#139111 (Properly document FakeReads) - rust-lang#139122 (Remove attribute `#[rustc_error]`) - rust-lang#139132 (Improve hir_pretty for struct expressions.) - rust-lang#139141 (Switch some rustc_on_unimplemented uses to diagnostic::on_unimplemented) r? `@ghost` `@rustbot` modify labels: rollup
Signed-off-by: xizheyin <[email protected]>
Remove mention of `exhaustive_patterns` from `never` docs
The example shows an exhaustive match:
```rust
#![feature(exhaustive_patterns)]
use std::str::FromStr;
let Ok(s) = String::from_str("hello");
```
But rust-lang#119612 moved this functionality to `#
remove `feature(inline_const_pat)` Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck. With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now: - we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types - we want the inline const pattern to participate in exhaustiveness checking - to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**. There are 4 possible ways to handle this: - stop typechecking inline const patterns together with their parent - causes inline const patterns to be different than inline const exprs - prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1` - region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn - inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck - difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing - do they carry their weight if they are now just equivalent to using an if-guard - delay exhaustiveness checking until after borrowck - should be possible in theory, but is a quite involved change and may have some unexpected challenges - remove this feature for now I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out. `const { .. }`-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920. r? types cc `@rust-lang/types` `@rust-lang/lang` rust-lang#76001
Fix UWP reparse point check Fixes rust-lang#138921
Updating anyhow v1.0.95 -> v1.0.97
Updating basic-toml v0.1.9 -> v0.1.10
Updating bitflags v2.8.0 -> v2.9.0
Updating blake3 v1.5.5 -> v1.8.0
Updating bumpalo v3.16.0 -> v3.17.0
Removing byteorder v1.5.0
Updating bytes v1.9.0 -> v1.10.1
Updating cargo_metadata v0.19.1 -> v0.19.2
Updating chrono v0.4.39 -> v0.4.40
Updating chrono-tz v0.10.1 -> v0.10.3
Updating chrono-tz-build v0.4.0 -> v0.4.1
Updating clap v4.5.26 -> v4.5.35
Updating clap_builder v4.5.26 -> v4.5.35
Updating clap_derive v4.5.24 -> v4.5.32
Updating console v0.15.10 -> v0.15.11
Updating cpufeatures v0.2.16 -> v0.2.17
Updating curl-sys v0.4.78+curl-8.11.0 -> v0.4.80+curl-8.12.1
Updating darling v0.20.10 -> v0.20.11
Updating darling_core v0.20.10 -> v0.20.11
Updating darling_macro v0.20.10 -> v0.20.11
Updating deranged v0.3.11 -> v0.4.0
Updating dissimilar v1.0.9 -> v1.0.10
Updating either v1.13.0 -> v1.15.0
Updating elsa v1.11.0 -> v1.11.2
Updating env_logger v0.11.6 -> v0.11.7
Updating equivalent v1.0.1 -> v1.0.2
Updating flate2 v1.0.35 -> v1.1.0
Updating foldhash v0.1.4 -> v0.1.5
Updating getrandom v0.3.1 -> v0.3.2
Updating globset v0.4.15 -> v0.4.16
Downgrading html5ever v0.29.2 -> v0.29.1 (available: v0.30.0)
Updating humantime v2.1.0 -> v2.2.0
Updating iana-time-zone v0.1.61 -> v0.1.63
Updating icu_list_data v1.5.0 -> v1.5.1
Updating icu_locid_transform_data v1.5.0 -> v1.5.1
Updating icu_normalizer_data v1.5.0 -> v1.5.1
Updating icu_properties_data v1.5.0 -> v1.5.1
Updating indexmap v2.7.0 -> v2.8.0
Updating indicatif v0.17.9 -> v0.17.11
Updating inout v0.1.3 -> v0.1.4
Updating itoa v1.0.14 -> v1.0.15
Adding jiff v0.2.5
Adding jiff-static v0.2.5
Updating jobserver v0.1.32 -> v0.1.33
Adding leb128fmt v0.1.0
Updating lexopt v0.3.0 -> v0.3.1
Updating libc v0.2.169 -> v0.2.171
Updating libz-sys v1.1.21 -> v1.1.22
Updating linux-raw-sys v0.4.15 -> v0.9.3
Updating litemap v0.7.4 -> v0.7.5
Updating log v0.4.25 -> v0.4.27
Downgrading markup5ever v0.15.0 -> v0.14.1
Updating miniz_oxide v0.8.3 -> v0.8.5
Updating once_cell v1.20.2 -> v1.21.3
Updating openssl-probe v0.1.5 -> v0.1.6
Updating openssl-sys v0.9.104 -> v0.9.106
Updating pest v2.7.15 -> v2.8.0
Updating pest_derive v2.7.15 -> v2.8.0
Updating pest_generator v2.7.15 -> v2.8.0
Updating pest_meta v2.7.15 -> v2.8.0
Updating pkg-config v0.3.31 -> v0.3.32
Updating portable-atomic v1.10.0 -> v1.11.0
Adding portable-atomic-util v0.2.4
Updating ppv-lite86 v0.2.20 -> v0.2.21
Updating proc-macro2 v1.0.93 -> v1.0.94
Updating quote v1.0.38 -> v1.0.40
Adding r-efi v5.2.0
Updating rand_core v0.9.0 -> v0.9.3
Updating redox_syscall v0.5.8 -> v0.5.10
Updating rustc-stable-hash v0.1.1 -> v0.1.2
Updating rustc_tools_util v0.4.0 -> v0.4.2
Updating rustix v0.38.43 -> v1.0.5
Updating rustversion v1.0.19 -> v1.0.20
Updating ryu v1.0.18 -> v1.0.20
Updating semver v1.0.24 -> v1.0.26
Updating serde v1.0.217 -> v1.0.219
Updating serde_derive v1.0.217 -> v1.0.219
Updating serde_json v1.0.135 -> v1.0.140
Updating similar v2.6.0 -> v2.7.0
Updating smallvec v1.13.2 -> v1.14.0
Updating socket2 v0.5.8 -> v0.5.9
Updating stacker v0.1.18 -> v0.1.20
Updating string_cache v0.8.8 -> v0.8.9
Updating syn v2.0.96 -> v2.0.100
Updating tar v0.4.43 -> v0.4.44
Updating tempfile v3.15.0 -> v3.19.1
Updating thin-vec v0.2.13 -> v0.2.14
Updating thiserror v2.0.11 -> v2.0.12
Updating thiserror-impl v2.0.11 -> v2.0.12
Updating time v0.3.37 -> v0.3.41
Updating time-core v0.1.2 -> v0.1.4
Updating time-macros v0.2.19 -> v0.2.22
Updating tinyvec v1.8.1 -> v1.9.0
Updating tokio v1.43.0 -> v1.44.1
Updating typenum v1.17.0 -> v1.18.0
Updating unicode-ident v1.0.14 -> v1.0.18
Updating uuid v1.12.0 -> v1.16.0
Updating wasi v0.13.3+wasi-0.2.2 -> v0.14.2+wasi-0.2.4
Removing wasm-encoder v0.219.1
Removing wasm-encoder v0.223.0
Adding wasm-encoder v0.219.2 (available: v0.228.0)
Adding wasm-encoder v0.223.1
Adding wasm-encoder v0.228.0
Updating wasm-metadata v0.223.0 -> v0.223.1
Removing wasmparser v0.219.1
Removing wasmparser v0.222.0
Removing wasmparser v0.223.0
Adding wasmparser v0.219.2 (available: v0.228.0)
Adding wasmparser v0.222.1
Adding wasmparser v0.223.1
Adding wasmparser v0.228.0
Updating wast v223.0.0 -> v228.0.0
Updating wat v1.223.0 -> v1.228.0
Updating windows-core v0.52.0 -> v0.61.0
Adding windows-implement v0.60.0
Updating windows-interface v0.59.0 -> v0.59.1
Adding windows-link v0.1.1
Updating windows-result v0.3.0 -> v0.3.2
Removing windows-strings v0.3.0
Adding windows-strings v0.3.1
Adding windows-strings v0.4.0
Updating wit-bindgen-rt v0.33.0 -> v0.39.0
Updating wit-component v0.223.0 -> v0.223.1
Updating wit-parser v0.223.0 -> v0.223.1
Updating xattr v1.4.0 -> v1.5.0
Removing zerocopy v0.7.35
Removing zerocopy v0.8.14
Adding zerocopy v0.8.24
Removing zerocopy-derive v0.7.35
Removing zerocopy-derive v0.8.14
Adding zerocopy-derive v0.8.24
Updating zerofrom v0.1.5 -> v0.1.6
Updating zerofrom-derive v0.1.5 -> v0.1.6
library dependencies
Updating dlmalloc v0.2.7 -> v0.2.8
Updating miniz_oxide v0.8.3 -> v0.8.5
Updating proc-macro2 v1.0.93 -> v1.0.94
Updating quote v1.0.38 -> v1.0.40
Updating rand_core v0.9.0 -> v0.9.3
Updating syn v2.0.98 -> v2.0.100
Updating unicode-ident v1.0.16 -> v1.0.18
Updating zerocopy v0.8.17 -> v0.8.24
Updating zerocopy-derive v0.8.17 -> v0.8.24
rustbook dependencies
Updating anyhow v1.0.95 -> v1.0.97
Updating bitflags v2.8.0 -> v2.9.0
Removing byteorder v1.5.0
Updating cc v1.2.10 -> v1.2.17
Updating chrono v0.4.39 -> v0.4.40
Updating clap v4.5.27 -> v4.5.32
Updating clap_builder v4.5.27 -> v4.5.32
Updating clap_complete v4.5.43 -> v4.5.47
Updating clap_derive v4.5.24 -> v4.5.32
Updating env_logger v0.11.6 -> v0.11.7
Updating equivalent v1.0.1 -> v1.0.2
Updating flate2 v1.0.35 -> v1.1.0
Updating getrandom v0.2.15 -> v0.3.2
Updating handlebars v6.3.0 -> v6.3.2
Removing humantime v2.1.0
Updating indexmap v2.7.1 -> v2.8.0
Updating itoa v1.0.14 -> v1.0.15
Adding jiff v0.2.5
Adding jiff-static v0.2.5
Updating libc v0.2.169 -> v0.2.171
Updating linux-raw-sys v0.4.15 -> v0.9.3
Updating litemap v0.7.4 -> v0.7.5
Updating log v0.4.25 -> v0.4.26
Updating mdbook-i18n-helpers v0.3.5 -> v0.3.6
Updating miniz_oxide v0.8.3 -> v0.8.5
Updating once_cell v1.20.2 -> v1.21.1
Removing phf_generator v0.10.0
Removing phf_shared v0.10.0
Updating pkg-config v0.3.31 -> v0.3.32
Adding portable-atomic v1.11.0
Adding portable-atomic-util v0.2.4
Removing ppv-lite86 v0.2.20
Updating proc-macro2 v1.0.93 -> v1.0.94
Removing pulldown-cmark v0.11.3
Updating pulldown-cmark-to-cmark v15.0.1 -> v20.0.1
Updating quote v1.0.38 -> v1.0.40
Adding r-efi v5.2.0
Removing rand_chacha v0.3.1
Updating redox_syscall v0.5.8 -> v0.5.10
Updating rustix v0.38.44 -> v1.0.3
Updating rustversion v1.0.19 -> v1.0.20
Updating ryu v1.0.19 -> v1.0.20
Updating semver v1.0.25 -> v1.0.26
Updating serde v1.0.217 -> v1.0.219
Updating serde_derive v1.0.217 -> v1.0.219
Updating serde_json v1.0.138 -> v1.0.140
Removing siphasher v0.3.11
Updating smallvec v1.13.2 -> v1.14.0
Updating string_cache v0.8.7 -> v0.8.8
Updating string_cache_codegen v0.5.2 -> v0.5.4
Updating syn v2.0.96 -> v2.0.100
Updating tempfile v3.15.0 -> v3.19.1
Updating terminal_size v0.4.1 -> v0.4.2
Updating textwrap v0.16.1 -> v0.16.2
Updating thiserror v2.0.11 -> v2.0.12
Updating thiserror-impl v2.0.11 -> v2.0.12
Updating toml v0.8.19 -> v0.8.20
Updating toml_edit v0.22.22 -> v0.22.24
Updating typenum v1.17.0 -> v1.18.0
Updating unicode-ident v1.0.16 -> v1.0.18
Updating wasi v0.11.0+wasi-snapshot-preview1 -> v0.14.2+wasi-0.2.4
Adding windows-link v0.1.1
Updating winnow v0.6.25 -> v0.7.4
Adding wit-bindgen-rt v0.39.0
Removing zerocopy v0.7.35
Removing zerocopy-derive v0.7.35
Updating zerofrom v0.1.5 -> v0.1.6
Updating zerofrom-derive v0.1.5 -> v0.1.6
…affleLapkin simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors It's not clear at all why the mask would have to be signed, it is anyway interpreted bitwise. The backend should just make sure that works no matter the surface-level type; our LLVM backend already does this correctly. The note of "the mask may be widened, which only has the correct behavior for signed integers" explains... nothing? Why can't the code do the widening correctly? If necessary, just cast to the signed type first... Also while we are at it, fix the errors. For simd_masked_load/store, the errors talked about the "third argument" but they meant the first argument (the mask is the first argument there). They also used the wrong type for `expected_element`. I have extremely low confidence in the GCC part of this PR. See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/On.20the.20sign.20of.20masks)
docs: fix typo change from inconstants to invariants
Add target-specific NaN payloads for the missing tier 2 targets This PR adds target-specific NaN payloads for the remaining tier 2 targets: - `arm64ec`: This target is a mix of `x86_64` and `aarch64`, meaning as they both have no extra payloads `arm64ec` also has no extra payloads. - `loongarch64`: Per [LoongArch Reference Manual - Volume 1: Basic Architecture](https://github.com/loongson/LoongArch-Documentation/releases/download/2023.04.20/LoongArch-Vol1-v1.10-EN.pdf) section 3.1.1.3, LoongArch does quieting NaN propagation with the Rust preferred NaN as its default NaN, meaning it has no extra payloads. - `nvptx64`: Per [PTX ISA documentation](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions) section 9.7.3 (and section 9.7.4 for `f16`), all payloads are possible. The documentation explicitly states that `f16` and `f32` operations result in an unspecified NaN payload, while for `f64` it states "NaN payloads are supported" without specifying how or what payload will be generated if there are no input NaNs. - `powerpc` and `powerpc64`: Per [Power Instruction Set Architecture](https://files.openpower.foundation/s/9izgC5Rogi5Ywmm/download/OPF_PowerISA_v3.1C.pdf) Book I section 4.3.2, PowerPC does quieting NaN propagation with the Rust preferred NaN being generated if no there are no input NaNs, meaning it has no extra payloads. - `s390x`: Per [IBM z/Architecture Principles of Operation](https://www.vm.ibm.com/library/other/22783213.pdf#page=965) page 9-3, s390x does quieting NaN propagation with the Rust's preferred NaN as its default NaN, meaning it has no extra payloads. Tracking issue: rust-lang#128288 cc ``@RalfJung`` ``@rustbot`` label +T-lang Also cc relevant target maintainers of tier 2 targets: - `arm64ec`: ``@dpaoliello`` - `loongarch64`: ``@heiher`` ``@xiangzhai`` ``@zhaixiaojuan`` ``@xen0n`` - `nvptx64`: ``@RDambrosio016`` ``@kjetilkjeka`` - `powerpc`: the only documented maintainer is ``@BKPepe`` for the tier 3 `powerpc-unknown-linux-muslspe`. - `powerpc64`: ``@daltenty`` ``@gilamn5tr`` ``@Gelbpunkt`` ``@famfo`` ``@neuschaefer`` - `s390x`: ``@uweigand`` ``@cuviper``
…enton Rollup of 5 pull requests Successful merges: - rust-lang#137953 (simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors) - rust-lang#139990 (transmutability: remove NFA intermediate representation) - rust-lang#140044 (rustc-dev-guide subtree update) - rust-lang#140051 (Switch exploit mitigations to mdbook footnotes) - rust-lang#140054 (docs: fix typo change from inconstants to invariants) r? `@ghost` `@rustbot` modify labels: rollup
…acrum
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 11 packages to latest compatible versions
Updating bstr v1.11.3 -> v1.12.0
Updating clap v4.5.35 -> v4.5.36
Updating clap_builder v4.5.35 -> v4.5.36
Updating crossbeam-channel v0.5.14 -> v0.5.15
Updating jiff v0.2.5 -> v0.2.6
Updating jiff-static v0.2.5 -> v0.2.6
Updating jsonpath-rust v1.0.0 -> v1.0.1
Updating linux-raw-sys v0.9.3 -> v0.9.4
Updating miniz_oxide v0.8.7 -> v0.8.8
Updating self_cell v1.1.0 -> v1.2.0
Updating winnow v0.7.4 -> v0.7.6
note: pass `--verbose` to see 38 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating miniz_oxide v0.8.7 -> v0.8.8
note: pass `--verbose` to see 4 unchanged dependencies behind latest
rustbook dependencies:
Locking 9 packages to latest compatible versions
Updating bstr v1.11.3 -> v1.12.0
Updating cc v1.2.18 -> v1.2.19
Updating clap v4.5.35 -> v4.5.36
Updating clap_builder v4.5.35 -> v4.5.36
Updating jiff v0.2.5 -> v0.2.6
Updating jiff-static v0.2.5 -> v0.2.6
Updating linux-raw-sys v0.9.3 -> v0.9.4
Updating miniz_oxide v0.8.7 -> v0.8.8
Updating winnow v0.7.4 -> v0.7.6
```
… r=jhpratt fix missing word in comment a very simple fix, rectifying a situation in which a word was accidentally .
…ratt SystemTime doc tweaks * Change the `UNIX_EPOCH` link in the `SystemTime` docs to point to the associated constant, not the module level constant. The former seems to be the recommended way to access it, since aiui the only reason the module constant exists in the first place is that associated constants weren't stable yet at the time. * Reword the comment in the `SystemTime` example - "an error occurred!" is a tad misleading; I feel like it implies a system error out of our control while `SystemTimeError` is more of a logic error. I was originally just gonna do the first thing but I noticed the second and figured I may as well. I'm also somewhat surprised that there aren't more in-depth module level docs for `std::time`; they don't even mention `SystemTime` at all. I might make another PR for that but mainly just wanted to flag it.
docs(LocalKey<T>): clarify that T's Drop shouldn't panic Clarify that should a TLS destructor panics, the process will abort. Also, an abort may be obfuscated as the process can be terminated with `SIGSEGV` or [`STATUS_STACK_BUFFER_OVERRUN`](https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655) (i.e., `SIGABRT` is not guaranteed), so explicitly prints that the process was aborted. Context: https://users.rust-lang.org/t/status-stack-buffer-overrun-on-windows-without-any-usage-of-unsafe/128417 ``@rustbot`` label -T-compiler
…ns, r=tgross35,Amanieu,traviscross Stabilize `naked_functions` tracking issue: rust-lang#90957 request for stabilization on tracking issue: rust-lang#90957 (comment) reference PR: rust-lang/reference#1689 # Request for Stabilization Two years later, we're ready to try this again. Even though this issue is already marked as having passed FCP, given the amount of time that has passed and the changes in implementation strategy, we should follow the process again. ## Summary The `naked_functions` feature has two main parts: the `#[naked]` function attribute, and the `naked_asm!` macro. An example of a naked function: ```rust const THREE: usize = 3; #[naked] pub extern "sysv64" fn add_n(number: usize) -> usize { // SAFETY: the validity of the used registers // is guaranteed according to the "sysv64" ABI unsafe { core::arch::naked_asm!( "add rdi, {}", "mov rax, rdi", "ret", const THREE, ) } } ``` When the `#[naked]` attribute is applied to a function, the compiler won't emit a [function prologue](https://en.wikipedia.org/wiki/Function_prologue_and_epilogue) or epilogue when generating code for this function. This attribute is analogous to [`__attribute__((naked))`](https://developer.arm.com/documentation/100067/0608/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----naked---function-attribute) in C. The use of this feature allows the programmer to have precise control over the assembly that is generated for a given function. The body of a naked function must consist of a single `naked_asm!` invocation, a heavily restricted variant of the `asm!` macro: the only legal operands are `const` and `sym`, and the only legal options are `raw` and `att_syntax`. In lieu of specifying operands, the `naked_asm!` within a naked function relies on the function's calling convention to determine the validity of registers. ## Documentation The Rust Reference: rust-lang/reference#1689 (Previous PR: rust-lang/reference#1153) ## Tests * [tests/run-make/naked-symbol-visiblity](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) verifies that `pub`, `#[no_mangle]` and `#[linkage = "..."]` work correctly for naked functions * [tests/codegen/naked-fn](https://github.com/rust-lang/rust/tree/master/tests/codegen/naked-fn) has tests for function alignment, use of generics, and validates the exact assembly output on linux, macos, windows and thumb * [tests/ui/asm/naked-*](https://github.com/rust-lang/rust/tree/master/tests/ui/asm) tests for incompatible attributes, generating errors around incorrect use of `naked_asm!`, etc ## Interaction with other (unstable) features ### [fn_align](rust-lang#82232) Combining `#[naked]` with `#[repr(align(N))]` works well, and is tested e.g. here - https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/aligned.rs - https://github.com/rust-lang/rust/blob/master/tests/codegen/naked-fn/min-function-alignment.rs It's tested extensively because we do need to explicitly support the `repr(align)` attribute (and make sure we e.g. don't mistake powers of two for number of bytes). ## History This feature was originally proposed in [RFC 1201](rust-lang/rfcs#1201), filed on 2015-07-10 and accepted on 2016-03-21. Support for this feature was added in [rust-lang#32410](rust-lang#32410), landing on 2016-03-23. Development languished for several years as it was realized that the semantics given in RFC 1201 were insufficiently specific. To address this, a minimal subset of naked functions was specified by [RFC 2972](rust-lang/rfcs#2972), filed on 2020-08-07 and accepted on 2021-11-16. Prior to the acceptance of RFC 2972, all of the stricter behavior specified by RFC 2972 was implemented as a series of warn-by-default lints that would trigger on existing uses of the `naked` attribute; these lints became hard errors in [rust-lang#93153](rust-lang#93153) on 2022-01-22. As a result, today RFC 2972 has completely superseded RFC 1201 in describing the semantics of the `naked` attribute. More recently, the `naked_asm!` macro was added to replace the earlier use of a heavily restricted `asm!` invocation. The `naked_asm!` name is clearer in error messages, and provides a place for documenting the specific requirements of inline assembly in naked functions. The implementation strategy was changed to emitting a global assembly block. In effect, an extern function ```rust extern "C" fn foo() { core::arch::naked_asm!("ret") } ``` is emitted as something similar to ```rust core::arch::global_asm!( "foo:", "ret" ); extern "C" { fn foo(); } ``` The codegen approach was chosen over the llvm naked function attribute because: - the rust compiler can guarantee the behavior (no sneaky additional instructions, no inlining, etc.) - behavior is the same on all backends (llvm, cranelift, gcc, etc) Finally, there is now an allow list of compatible attributes on naked functions, so that e.g. `#[inline]` is rejected with an error. The `#[target_feature]` attribute on naked functions was later made separately unstable, because implementing it is complex and we did not want to block naked functions themselves on how target features work on them. See also rust-lang#138568. relevant PRs for these recent changes - rust-lang#127853 - rust-lang#128651 - rust-lang#128004 - rust-lang#138570 - ### Various historical notes #### `noreturn` [RFC 2972](https://github.com/rust-lang/rfcs/blob/master/text/2972-constrained-naked.md) mentions that naked functions > must have a body which contains only a single asm!() statement which: > iii. must contain the noreturn option. Instead of `asm!`, the current implementation mandates that the body contain a single `naked_asm!` statement. The `naked_asm!` macro is a heavily restricted version of the `asm!` macro, making it easier to talk about and document the rules of assembly in naked functions and give dedicated error messages. For `naked_asm!`, the behavior of the `asm!`'s `noreturn` option is implicit. The `noreturn` option means that it is UB for control flow to fall through the end of the assembly block. With `asm!`, this option is usually used for blocks that diverge (and thus have no return and can be typed as `!`). With `naked_asm!`, the intent is different: usually naked funtions do return, but they must do so from within the assembly block. The `noreturn` option was used so that the compiler would not itself also insert a `ret` instruction at the very end. #### padding / `ud2` A `naked_asm!` block that violates the safety assumption that control flow must not fall through the end of the assembly block is UB. Because no return instruction is emitted, whatever bytes follow the naked function will be executed, resulting in truly undefined behavior. There has been discussion whether rustc should emit an invalid instruction (e.g. `ud2` on x86) after the `naked_asm!` block to at least fail early in the case of an invalid `naked_asm!`. It was however decided that it is more useful to guarantee that `#[naked]` functions NEVER contain any instructions besides those in the `naked_asm!` block. # unresolved questions None r? ``@Amanieu`` I've validated the tests on x86_64 and aarch64
Hermit: Unify `std::env::args` with Unix The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix. The atomic orderings were established in rust-lang#74006 (cc `@euclio)` for Unix and rust-lang#100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match. Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit. cc `@mkroening` `@stlankes` for Hermit
…r=joboet Clarify why SGX code specifies linkage/symbol names for certain statics Specifying linkage/symbol name is solely to ensure a single instance between the `std` crate and its unit tests. Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
…er-errors cleanup redundant pattern instances Just two small code cleanups.
{B,C}Str: minor cleanup
(hopefully) uncontroversial bits extracted from rust-lang#139994.
…enton Rollup of 11 pull requests Successful merges: - rust-lang#134213 (Stabilize `naked_functions`) - rust-lang#139711 (Hermit: Unify `std::env::args` with Unix) - rust-lang#139795 (Clarify why SGX code specifies linkage/symbol names for certain statics) - rust-lang#140036 (Advent of `tests/ui` (misc cleanups and improvements) [4/N]) - rust-lang#140047 (remove a couple clones) - rust-lang#140052 (Fix error when an intra doc link is trying to resolve an empty associated item) - rust-lang#140074 (rustdoc-json: Improve test for auto-trait impls) - rust-lang#140076 (jsondocck: Require command is at start of line) - rust-lang#140107 (rustc-dev-guide subtree update) - rust-lang#140111 (cleanup redundant pattern instances) - rust-lang#140118 ({B,C}Str: minor cleanup) r? `@ghost` `@rustbot` modify labels: rollup
Update `libc` to 0.2.172 r? ````@joboet````
carolynzech
approved these changes
Apr 23, 2025
tautschnig
approved these changes
Apr 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automated PR to merge library subtree updates from 2025-04-21 (rust-lang/rust@b8c54d6) to 2025-04-23 (rust-lang/rust@6bc57c6), inclusive. This is a clean merge, no conflicts were detected. Do not remove or edit the following annotations:
git-subtree-dir: library
git-subtree-split: 54a7b4f