Merge subtree update for toolchain nightly-2025-03-18 #20
Conversation
This file contains 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}
these all also accept integer vectors as arguments
this is because they may be widened, and that only works when sign extension is used: zero extension would produce invalid results
This patch makes BufReader::peek()'s doctest call read_more() to refill the buffer before the inner reader hits EOF. This exposes a bug in read_more() that causes an out-of-bounds slice access and segfault.
Buffer::read_more() is supposed to refill the buffer without discarding its contents, which are in the range `pos .. filled`. It mistakenly borrows the range `pos ..`, fills that, and then increments `filled` by the amount read. This overwrites the buffer's existing contents and sets `filled` to a too-large value that either exposes uninitialized bytes or walks off the end of the buffer entirely. This patch makes it correctly fill only the unfilled portion of the buffer, which should maintain all the type invariants and fix the test failure introduced in commit b119671.
…oss35 checked_ilog tests: deal with a bit of float imprecision Fixes rust-lang#137591 r? `@tgross35`
Use correct error message casing for `io::const_error`s Error messages are supposed to start with lowercase letters, but a lot of `io::const_error` messages did not. This fixes them to start with a lowercase letter. I did consider adding a const check for this to the macro, but some of them start with proper nouns that make sense to uppercase them. See https://doc.rust-lang.org/1.85.0/std/error/trait.Error.html
…s, r=workingjubilee Fix inaccurate `std::intrinsics::simd` documentation This addresses two issues: - the docs on comparison operators (`simd_gt` etc.) said they only work for floating-point vectors, but they work for integer vectors too. - the docs on various functions that use a mask did not document that the mask must be a signed integer vector. Unsigned integer vectors would cause invalid behavior when the mask vector is widened (unsigned integers would use zero extension, producing incorrect results). r? ``@workingjubilee``
- Some UEFI protocols such as TCP4, TCP6, UDP4, UDP6, etc are managed by service binding protocol. - A new instance of such protocols is created and destroyed using the corresponding service binding protocol. - This PR adds abstractions to make using such protocols simpler using Rust Drop trait. - The reason to add these abstractions in a seperate PR from TCP4 Protocol is to make review easier. [EFI_SERVICE_BINDING_PROTCOL](https://uefi.org/specs/UEFI/2.11/11_Protocols_UEFI_Driver_Model.html#efi-service-binding-protocol) Signed-off-by: Ayush Singh <[email protected]>
Includes a change to make a subset of math symbols available on all platforms [1], and disables `f16` on aarch64 without neon [2]. [1]: rust-lang/compiler-builtins#763 [2]: rust-lang/compiler-builtins#775
One-sided ranges are never empty
LLVM has crashes at some `half` operations when built with assertions enabled if fp-armv8 is not available [1]. Things seem to usually work, but we are reaching LLVM undefined behavior so this needs to be disabled. [1]: llvm/llvm-project#129394
These constants can be useful outside of their current module. Make them `pub(crate)` to allow for this.
Fix or elaborate existing float parsing documentation. This includes introducing a convention that should make naming more consistent.
This module currently contains two decimal types, `Decimal` and `Number`. These names don't provide a whole lot of insight into what exactly they are, and `Number` is actually the one that is more like an expected `Decimal` type. In accordance with this, rename the existing `Decimal` to `DecimalSeq`. This highlights that it contains a sequence of decimal digits, rather than representing a base-10 floating point (decimal) number. Additionally, add some tests to validate internal behavior.
The previous commit renamed `Decimal` to `DecimalSeq`. Now, rename the type that represents a decimal floating point number to be `Decimal`. Additionally, add some tests for internal behavior.
A lot of the magic constants can be turned into expressions. This reduces some code duplication. Additionally, add traits to make these operations fully generic. This will make it easier to support `f16` and `f128`.
This is just a bit of code cleanup to make use of returning early.
This is an attempt to fix rust-lang#135087 together with rust-lang#135886, but I am not sure if I've succeeded in adding much clarity here, so don't be shy with your comments.
- UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths - This PR has been split off from rust-lang#135368 for easier review. The allow dead_code will be removed in rust-lang#135368 Signed-off-by: Ayush Singh <[email protected]>
…, r=Mark-Simulacrum Minor internal comments fix for `BufRead::read_line` Just a little fix that came up while I was reading through this source code, and had to search for a few minutes to find out what was actually *meant* here.
More precisely document `Global::deallocate()`'s safety. There is a subtlety which "other conditions must be upheld by the caller" does not capture: `GlobalAlloc`/`alloc::dealloc()` require that the provided layout will be *equal*, not just that it "fits", the layout used to allocate. This is always true here due to how `allocate()`, `grow()`, and `shrink()` are implemented (they never return a larger allocation than requested), but that is a non-local property of the implementation, so it should be documented explicitly. r? libs `@rustbot` label A-allocators
…ct, r=scottmcm fix `RangeBounds::is_empty` documentation One-sided ranges are never empty follow-up for rust-lang#137304 (review)
… r=workingjubilee Disable `f16` on Aarch64 without `neon` LLVM has crashes at some `half` operations when built with assertions enabled if fp-armv8 is not available [1]. Things seem to usually work, but we are reaching LLVM undefined behavior so this needs to be disabled. [1]: llvm/llvm-project#129394
this doesn't fix any bugs, it just looks more consistent with the other impl's
…imulacrum Make phantom variance markers transparent
…iaskrgr Rollup of 12 pull requests Successful merges: - rust-lang#135767 (Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies) - rust-lang#137852 (Remove layouting dead code for non-array SIMD types.) - rust-lang#137863 (Fix pretty printing of unsafe binders) - rust-lang#137882 (do not build additional stage on compiler paths) - rust-lang#137894 (Revert "store ScalarPair via memset when one side is undef and the other side can be memset") - rust-lang#137902 (Make `ast::TokenKind` more like `lexer::TokenKind`) - rust-lang#137921 (Subtree update of `rust-analyzer`) - rust-lang#137922 (A few cleanups after the removal of `cfg(not(parallel))`) - rust-lang#137939 (fix order on shl impl) - rust-lang#137946 (Fix docker run-local docs) - rust-lang#137955 (Always allow rustdoc-json tests to contain long lines) - rust-lang#137958 (triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search) r? `@ghost` `@rustbot` modify labels: rollup
…mulacrum Expand `CloneToUninit` documentation. * Clarify relationship to `dyn` after rust-lang#133003. * Add an example of using it with `dyn` as rust-lang#133003 enabled. * Replace parameter name `dst` with `dest` to avoid confusion between abbreviations for “DeSTination” and “Dynamically-Sized Type”. * Add an example of implementing it. * Add links to Rust Reference for the mentioned concepts. * Mention that its method should rarely be called. * Various small corrections. Please review the `unsafe` code closely, as I am not an expert in the best possible ways to express these operations. (It might also be better to omit the implementation example entirely.) cc `@zachs18` rust-lang#126799
…onsume, r=Mark-Simulacrum doc: clarify that consume can be called after BufReader::peek tracking issue rust-lang#128405
…thomcc Remove `#[cfg(not(test))]` gates in `core` These gates are unnecessary now that unit tests for `core` are in a separate package, `coretests`, instead of in the same files as the source code. They previously prevented the two `core` versions from conflicting with each other.
…-detected, r=Mark-Simulacrum expose `is_s390x_feature_detected!` from `std::arch` tracking issue: rust-lang#135413 implementation: rust-lang/stdarch#1699 (more features added in rust-lang/stdarch#1720) This macro was part of the recent `stdarch` synchronization, but not yet exposed via `std::arch`. r? libs
Fix Ptr inconsistency in {Rc,Arc}
### PR Description
This pr aims to address the problem discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Inconsistency.20in.20.7BRc.2CArc.7D's.20ptr.20requirements/with/504259637).
### Problem Clarification
As this post presents, the `{Rc, Arc}::{in/de-crement_strong_count_/in}` do not limit the layout of the memory that `ptr` points to, while internally `Rc::from_raw_in` is called directly.
UB doesn't just appear when the strong count is decremented to zero. Miri also detects the UB of `out-of-bounds pointer use` when increment strong count is called on a pointer with an incorrect layout(shown as below).
```rust
use std::rc::Rc;
#[repr(align(8))]
struct Aligned8(u64);
#[repr(align(16))]
struct Aligned16(u64);
fn main() {
let rc: Rc<Aligned8> = Rc::new(Aligned8(42));
let raw_ptr = Rc::into_raw(rc);
unsafe {
Rc::increment_strong_count(raw_ptr as *const Aligned16);
}
}
```
Miri output:
```
error: Undefined Behavior: out-of-bounds pointer use: expected a pointer to 32 bytes of memory, but got alloc954 which is only 24 bytes from the end of the allocation
```
Add missing doc for intrinsic (Fix PR135334) The previous [PR135334](rust-lang#135334) mentioned that some of the intrinsic APIs were missing safety descriptions. Among intrinsic APIs that miss safety specifications, most are related to numerical operations. They might need to be discussed and then seen how to organize. Apart from them, only a few intrinsics lack safety. So this PR deals with the APIs with non-numerical operations in priority.
…acrum Expand and organize `offset_of!` documentation. * Give example of how to get the offset of an unsized tail field (prompted by discussion <rust-lang#133055 (comment)>). * Specify the return type. * Add section headings. * Reduce “Visibility is respected…”, to a single sentence. * Move `offset_of_enum` documentation to unstable book (with link to it). * Add `offset_of_slice` documentation in unstable book. r? Mark-Simulacrum
…acrum debug-assert that the size_hint is well-formed in `collect` Closes rust-lang#137919 In the hopes of helping to catch any future accidentally-incorrect rustc or stdlib iterators (like the ones rust-lang#137908 accidentally found), this has `Iterator::collect` call `size_hint` and check its `low` doesn't exceed its `Some(high)`. There's of course a bazillion more places this *could* be checked, but the hope is that this one is a good tradeoff of being likely to catch lots of things while having minimal maintenance cost (especially compared to putting it in *every* container's `from_iter`).
core: Make `Debug` impl of raw pointers print metadata if present Make Rust pointers appear less magic by including metadata information in their `Debug` output. This does not break Rust stability guarantees because `Debug` impl are explicitly exempted from stability: https://doc.rust-lang.org/std/fmt/trait.Debug.html#stability > ## Stability > > Derived `Debug` formats are not stable, and so may change with future Rust versions. Additionally, `Debug` implementations of types provided by the standard library (`std`, `core`, `alloc`, etc.) are not stable, and may also change with future Rust versions. Note that a regression test is added as a separate commit to make it clear what impact the last commit has on the output. Closes rust-lang#128684 because the output of that code now becomes: ``` thread 'main' panicked at src/main.rs:5:5: assertion `left == right` failed left: Pointer { addr: 0x7ffd45c6fc6b, metadata: 5 } right: Pointer { addr: 0x7ffd45c6fc6b, metadata: 3 } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ```
libstd: rustdoc: correct note on fds 0/1/2 pre-main Closes: rust-lang#137490
fix doc path in std::fmt macro fixes rust-lang#137519
… r=jhpratt Optimize multi-char string patterns Uses specialization for `[T]::contains` from rust-lang#130991 to optimize multi-char patterns in string searches. Requesting a perf run to see if this actually has an effect 🙏 (I think that adding `char` to the list of types for which the `SliceContains` is specialized is a good idea, even if it doesn't show up on perf - might be helpful for downstream users)
It's bitflags in practice, so an enum is unsound, as an enum must only have the described values. The x86_64 psABI declares it as a `typedef int _Unwind_Action`, which seems reasonable. I made a newtype first but that was more annoying than just a typedef. We don't really use this value for much other than a short check.
…=Amanieu
Add `From<{integer}>` for `f16`/`f128` impls
This PR adds `impl From<{bool,i8,u8}> for f16` and `impl From<{bool,i8,u8,i16,u16,i32,u32}> for f128`.
The `From<{i64,u64}> for f128` impls are left commented out as adding them would allow using `f128` on stable before it is stabilised like in the following example:
```rust
fn f<T: From<u64>>(x: T) -> T { x }
fn main() {
let x = f(1.0); // the type of the literal is inferred to be `f128`
}
```
None of the impls added in this PR have this issue as they are all, at minimum, also implemented by `f64`.
This PR will need a crater run for the `From<{i32,u32}>` impls, as `f64` is no longer the only float type to implement them (similar to the cause of rust-lang#125198).
cc `@bjoernager`
r? `@tgross35`
Tracking issue: rust-lang#116909
document capacity for ZST as example The main text already covers this, although it provides weaker guarantees, but I think an example in the right spot does not hurt. Fixes rust-lang#80747
doc all differences of ptr:copy(_nonoverlapping) with memcpy and memmove Fixes rust-lang#79430
…, r=workingjubilee Make `_Unwind_Action` a type alias, not enum It's bitflags in practice, so an enum is unsound, as an enum must only have the described values. The x86_64 psABI declares it as a `typedef int _Unwind_Action`, which seems reasonable. I made a newtype first but that was more annoying than just a typedef. We don't really use this value for much other than a short check. I ran `x check library --target aarch64-unknown-linux-gnu,x86_64-pc-windows-gnu,x86_64-fortanix-unknown-sgx,x86_64-unknown-haiku,x86_64-unknown-fuchsi a,x86_64-unknown-freebsd,x86_64-unknown-dragonfly,x86_64-unknown-netbsd,x86_64-unknown-openbsd,x86_64-unknown-redox,riscv64-linux-android,armv7-unknown-freebsd` (and some more but they failed to build for other reasons :D) fixes rust-lang#138558 r? workingjubilee have fun
Rollup of 5 pull requests Successful merges: - rust-lang#136293 (document capacity for ZST as example) - rust-lang#136359 (doc all differences of ptr:copy(_nonoverlapping) with memcpy and memmove) - rust-lang#136816 (refactor `notable_traits_button` to use iterator combinators instead of for loop) - rust-lang#138552 (Misc print request handling cleanups + a centralized test for print request stability gating) - rust-lang#138573 (Make `_Unwind_Action` a type alias, not enum) r? `@ghost` `@rustbot` modify labels: rollup
…e_retrieval_methods, r=Amanieu Add `*_value` methods to proc_macro lib This is the implementation of rust-lang/libs-team#459. It allows to get the actual value (unescaped) of the different string literals. Part of rust-lang#136652. r? libs-api
Add std support to cygwin target
…r=joshtriplett Stablize anonymous pipe Since rust-lang#135822 is staled, I create this PR to stablise anonymous pipe Closes rust-lang#127154 try-job: test-various
std: Mention clone-on-write mutation in Arc<T> Fixes rust-lang#138322 r? libs
…anieu,lnicola Denote `ControlFlow` as `#[must_use]` I've repeatedly hit bugs in the compiler due to `ControlFlow` not being marked `#[must_use]`. There seems to be an accepted ACP to make the type `#[must_use]` (rust-lang/libs-team#444), so this PR implements that part of it. Most of the usages in the compiler that trigger this new warning are "root" usages (calling into an API that uses control-flow internally, but for which the callee doesn't really care) and have been suppressed by `let _ = ...`, but I did legitimately find one instance of a missing `?` and one for a never-used `ControlFlow` value in rust-lang#137448. Presumably this needs an FCP too, so I'm opening this and nominating it for T-libs-api. This PR also touches the tools (incl. rust-analyzer), but if this went into FCP, I'd split those out into separate PRs which can land before this one does. r? libs-api `@rustbot` label: T-libs-api I-libs-api-nominated
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-03-17 (rust-lang/rust@227690a) to 2025-03-18 (rust-lang/rust@43a2e9d), 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: 8902bd3