-
Notifications
You must be signed in to change notification settings - Fork 48
Merge subtree update for toolchain nightly-2025-03-18 #309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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
… 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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving as these are the same changes as in #308 plus the toolchain/Kani config changes. (Nevermind the spurious >= 10k commits as that is just the effect of past squash merges.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No merge conflicts 🙌
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