Rollup of 14 pull requests - #160310
Merged
Merged
Conversation
Constructing an Rc<[T]> or Arc<[T]> whose header + payload layout exceeds isize::MAX unwrapped a LayoutError, panicking with the opaque "called `Result::unwrap()` on an `Err` value: LayoutError". Match Vec and Box by reporting "capacity overflow" instead, and add regression tests.
This FIXME was added in [1], at which point there were 8 arguments. Now there are only 5, which is much more reasonable. This commit was brought to you by https://oli-obk.github.io/fixmeh/. [1]: rust-lang#78923
Forbid super/crate/self/Self to be used in register_tool. Also, add test for raw identifier and unicode identifiers.
This adds back the previously existing duplicate tool error, but as a suppressable lint.
This is already *supposed* to be impossible in layout, but this emphasizes that better. Ironically I was inspired to do this as part of looking at making `Simd<T, 0>` *work*, but importantly if that's going to happen I think it should be `BackendRepr::Memory` like other ZSTs, *not* a `BackendRepr::ScalarVector` that would need to carry around a useless LLVM value in `OperandValue::Immediate` (where it's not even clear what the LLVM type of that value would be).
* docs: document the non_exhaustive attribute * Add newline at end of attribute_docs.rs * Update library/core/src/attribute_docs.rs * Update library/core/src/attribute_docs.rs Co-authored-by: Guillaume Gomez <contact@guillaume-gomez.fr> Co-authored-by: Krisitan Erik Olsen <kristian.erik@outlook.com>
* fundamental only on first arg * woo this made error messages nicer * oh the test was misnamed lol * special case only box * rename tests Co-authored-by: Nia Deckers <nia-e@haecceity.cc>
Instead of displaying all kind of tuples that implement a given trait, which might flood the user, it displays a concise message only when all the involved types are tuples.
…-5, r=saethlin Emit retags in codegen to support BorrowSanitizer (part 5) Tracking issue: rust-lang#154760 [Zulip Thread](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Staging.20for.20emitting.20retags.20in.20codegen/with/592364811) This is one of several PRs that add experimental support for emitting retags as function calls in codegen. This PR adds support for emitting global arrays that specify the ranges of interior mutable and pinned data. For example, ```rust fn cell(x: &(i32, Cell<i32>)) { ... } ``` This program will have IR similar to the following: ```llvm @anon.0 = unnamed_addr constant [16 x i8] c"\04...\04..." define void @cell(ptr %0) { start: %x = call ptr @__rust_retag_reg(ptr %0, i64 8, i8 1, ptr @anon.0, ptr null) ... } ``` The last four bytes at offset four are interior mutable. Users can disable this behavior by passing `no-precise-im` or `no-precise-pin` as options to `-Zcodegen-emit-retag`. In that case, the last two parameters to the retag intrinsic will always be null pointers. BorrowSanitizer will be able to switch to using nightly once this is merged. Thank you @saethlin for reviewing these PRs! Note: we still do not support retagging SIMD types, since cg-ssa does not support `insertelement`. Related: rust-lang#158100 Cc: @RalfJung r? @saethlin
…overflow, r=JohnTitor Report "capacity overflow" for oversized Rc<[T]>/Arc<[T]> Fixes rust-lang#136797. Building an Rc<[T]>/Arc<[T]> whose header + payload layout exceeds isize::MAX unwrapped a LayoutError and panicked with "called Result::unwrap() on an Err value: LayoutError". Vec and Box report "capacity overflow" here; this makes Rc/Arc do the same. Used an inline panic!("capacity overflow") rather than raw_vec's capacity_overflow(), since that helper is cfg'd out under no_global_oom_handling while these two layout fns still compile there.
make atomic operations const In a similar vein to rust-lang#159094, it makes sense to make these `const fn` so that code can be shared between compile-time and run-time even if the runtime version has to deal with concurrency. This constifies the following: ```rust // core::sync::atomic impl AtomicBool { pub const fn get_mut(&mut self) -> &mut bool; pub const fn from_mut(v: &mut bool) -> &mut Self; pub const fn get_mut_slice(this: &mut [Self]) -> &mut [bool]; pub const fn from_mut_slice(v: &mut [bool]) -> &mut [Self]; pub const fn load(&self, order: Ordering) -> bool; pub const fn store(&self, val: bool, order: Ordering); pub const fn swap(&self, val: bool, order: Ordering) -> bool; pub const fn compare_and_swap(&self, current: bool, new: bool, order: Ordering) -> bool; pub const fn compare_exchange( &self, current: bool, new: bool, success: Ordering, failure: Ordering, ) -> Result<bool, bool>; pub const fn compare_exchange_weak( &self, current: bool, new: bool, success: Ordering, failure: Ordering, ) -> Result<bool, bool>; pub const fn fetch_and(&self, val: bool, order: Ordering) -> bool; pub const fn fetch_nand(&self, val: bool, order: Ordering) -> bool; pub const fn fetch_or(&self, val: bool, order: Ordering) -> bool; pub const fn fetch_xor(&self, val: bool, order: Ordering) -> bool; pub const fn fetch_not(&self, order: Ordering) -> bool; } impl AtomicPtr<T> { pub const fn get_mut(&mut self) -> &mut *mut T; pub const fn from_mut(v: &mut *mut T) -> &mut Self; pub const fn get_mut_slice(this: &mut [Self]) -> &mut [*mut T]; pub const fn from_mut_slice(v: &mut [*mut T]) -> &mut [Self]; pub const fn load(&self, order: Ordering) -> *mut T; pub const fn store(&self, ptr: *mut T, order: Ordering); pub const fn swap(&self, ptr: *mut T, order: Ordering) -> *mut T; } impl Atomic$Int { pub const fn get_mut(&mut self) -> &mut $int_type; pub const fn from_mut(v: &mut $int_type) -> &mut Self; pub const fn get_mut_slice(this: &mut [Self]) -> &mut [$int_type]; pub const fn from_mut_slice(v: &mut [$int_type]) -> &mut [Self]; pub const fn load(&self, order: Ordering) -> $int_type; pub const fn store(&self, val: $int_type, order: Ordering); pub const fn swap(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn compare_and_swap(&self, current: $int_type, new: $int_type, order: Ordering) -> $int_type; pub const fn compare_exchange(&self, current: $int_type, new: $int_type, success: Ordering, failure: Ordering) -> Result<$int_type, $int_type>; pub const fn compare_exchange_weak(&self, current: $int_type, new: $int_type, success: Ordering, failure: Ordering) -> Result<$int_type, $int_type>; pub const fn fetch_add(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn fetch_sub(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn fetch_and(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn fetch_nand(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn fetch_or(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn fetch_xor(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn fetch_max(&self, val: $int_type, order: Ordering) -> $int_type; pub const fn fetch_min(&self, val: $int_type, order: Ordering) -> $int_type; } pub const fn fence(order: Ordering); pub const fn compiler_fence(order: Ordering); ``` However, this excludes the `fetch_*` and `compare_*` operations on `AtomicPtr`, as that kind of pointer arithmetic is not possible at compile time. Tracking issue: rust-lang#160078 Cc @rust-lang/wg-const-eval @rust-lang/opsem
Structurally prevent zero-count `BackendRepr::SimdVector`s This is already *supposed* to be impossible in layout, but this emphasizes that better. This PR makes no behaviour changes; just `BackendLaneCount` instead of `u64` in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html Ironically I was inspired to do this as part of [looking at making `Simd<T, 0>` *work*](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/Allow.20N.3D.3D0.3F/with/613345298), but importantly if that's going to happen I think it should be `BackendRepr::Memory` like other ZSTs, *not* a `BackendRepr::ScalarVector` that would need to carry around a useless LLVM value in `OperandValue::Immediate` (where it's not even clear what the LLVM type of that value would be).
Make `#[fundamental]` only apply to the first argument of `Box` Per a [discussion with lang](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/.60.23.5Bfundamental.5D.60.20and.20.60Box.3CT.2C.20A.3E.60/with/613236766), it was decided that we want `Box<T, A>` to only be fundamental in `T`. ~~Given that `Box` is the only fundamental type with two generic params, simply make it so only the first param is considered for fundamentalness.~~ ~~`Tuple` is also fundamental, but has its own path in coherence checking and so isn't impacted by this; `Box` is the only thing that is.~~ Since this is just an internal detail and `#[fundamental]` is not in a rush to get stabilised, lang's opinion was that t-compiler has free rein on how to implement this so I figured I'd go with the most straightforward implementation for now. The main alternative I see would be supporting param-position `#[fundamental]` & have the semantics that: ```rust #[fundamental] struct Foo<T, U>(T, U); ``` is equivalent to ```rust struct Foo<#[fundamental] T, #[fundamental] U>(T, U); ``` though given that there's no usecase for this right now, it seemed somewhat unnecessary. r? compiler
Remove an outdated FIXME This FIXME was added in rust-lang#78923, at which point there were 8 arguments. Now there are only 5, which is much more reasonable. This commit was brought to you by https://oli-obk.github.io/fixmeh/.
…rochenkov Improve diagnostic for patterns in function pointer types In preparation for some work for rust-lang#158499 Diagnostic before: ``` error[E0642]: patterns aren't allowed in methods without bodies --> $DIR/fn-ptr-pattern.rs:4:14 | LL | pat2: fn(1..3: bool), | ^^^^ | help: give this argument a name or use an underscore to ignore it | LL - pat2: fn(1..3: bool), LL + pat2: fn(_: bool), | ``` Diagnostic after: ``` error[E0642]: patterns aren't allowed in function pointer types --> $DIR/fn-ptr-pattern.rs:4:14 | LL | pat2: fn(1..3: bool), | ^^^^ | help: give this argument a name or use an underscore to ignore it | LL - pat2: fn(1..3: bool), LL + pat2: fn(_: bool), | ```
Eagerly fetch typeck results when linting The first commit avoids running the lint visitor if all lints were filtered out. In every other case the typeck results are accessed on every body making the delayed load pointless overhead.
…it_impls_tuples, r=mejrs Improve suggestions when multiples tuples implement the same trait Fixes rust-lang#152903
…ttribute, r=GuillaumeGomez Add documentation for the `non_exhaustive` attribute Document the built-in `non_exhaustive` attribute using the `#[doc(attribute = "…")]` mechanism. Part of rust-lang#157604 Tested with `./x test library/std --doc --test-args attribute_docs`. r? @GuillaumeGomez
Member
Author
Contributor
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 1, 2026
Rollup of 14 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-*
This comment has been minimized.
This comment has been minimized.
Contributor
Contributor
This was referenced Aug 1, 2026
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing cb9d1b0 (parent) -> b6a3d79 (this PR) Test differencesShow 3207 test diffsStage 1
Stage 2
Additionally, 3182 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard b6a3d7965e2c5de79378a88a3f28a6f1b73fbb16 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: cb9d1b0640 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Collaborator
|
Finished benchmarking commit (b6a3d79): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 0.8%, secondary 0.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 0.1%, secondary -0.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 490.618s -> 491.498s (0.18%) |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
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.
Successful merges:
BackendRepr::SimdVectors #160124 (Structurally prevent zero-countBackendRepr::SimdVectors)#[fundamental]only apply to the first argument ofBox#160162 (Make#[fundamental]only apply to the first argument ofBox)non_exhaustiveattribute #159861 (Add documentation for thenon_exhaustiveattribute)hidden_glob_reexportsinrustc_ast#159907 (Fixhidden_glob_reexportsinrustc_ast)minifierversion to0.4.0#160307 (Updateminifierversion to0.4.0)r? @ghost
Create a similar rollup