Rollup of 18 pull requests#158753
Open
jhpratt wants to merge 52 commits into
Open
Conversation
The compiler is removing the `x86-softfloat` [1], thus temporarily add a patch. As usual, the patch will eventually make it to the Linux kernel so that both sides are good. Cc: Ralf Jung <post@ralfj.de> Cc: Alice Ryhl <aliceryhl@google.com> Link: rust-lang#157151 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The auto-trait branch of the orphan check inspected the unexpanded self
type, so an impl whose self type was a free (lazy) type alias was
rejected even when the alias resolved to an otherwise valid nominal
type, e.g. `unsafe impl Sync for Alias {}` with `type Alias = Local;`.
Expand free alias types before classifying the self type, mirroring the
locality check above. Expansion still reveals genuinely problematic self
types (trait objects, opaque types, type parameters), so those keep
being rejected.
…s a standalone command - error if RUSTC isn't set, which means it'll fall back to the user-installed default (wrong) - be more specific in `--bless` suggestions that they should use `x test tidy`, not tidy directly.
for non-interactive cases, such as CI, this makes it easier to tell what went wrong without having to interactively debug the problem.
Before this commit, `BlameConstraint` is a bit hard to understand at first, because of its `ObligationCause` field. In practice, `BlameConstraint` is just a slimmed down version of an `OutlivesConstraint` from `Vec<OutlivesConstraint>`. The artificial `ObligationCause` is only needed in one place. Rather than having that exception polute the lower level analysis, bubble it up as much as we can. That way, it becomes clearer what `BlameConstraint` actually is. For reference, `ObligationCause` was introdued by 93ab12e, but the codebase looked quite different back then.
Porting the notes from the stable branch.
…back Co-authored-by: Vin <betadelphini.py@gmail.com>
All call sites use a static `DropKind` value, and we already have a dedicated named method for lints. Switch to only use dedicated methods for consistency.
This enforces the invariant that `size_hint` should always return `(lower_bound(), upper_bound())`.
Leaving the trait in a better state than it previously was. Co-Authored-By: Clar Fon <15850505+clarfonthey@users.noreply.github.com>
Co-authored-by: Jubilee <workingjubilee@gmail.com>
…_alias_expansion, r=fmease expand free alias types in the auto-trait orphan check fixes rust-lang#157756. auto-trait impls are only allowed on nominal types. the check for that looked at the self type as written, without expanding it, so a lazy type alias got rejected even when it pointed straight at a type that's fine on its own: ```rust #![feature(lazy_type_alias)] struct Local; type Alias = Local; unsafe impl Sync for Alias {} // used to be E0321 ``` the locality check right above it already normalizes the self type, so the two were looking at different things. imo the cleanest fix is to expand free aliases first, with the same `expand_free_alias_tys` coherence already calls in a couple of other spots. anything that should still be rejected (trait objects, opaque types, bare type params) survives the expansion and errors like before. one thing worth a second look: `impl_for_weak_alias.rs` used `type Alias = (impl Sized, u8)` and expected an error. idk if that was deliberate, but the alias expands to a tuple, and a tuple is fine for a local auto trait if you write it by hand, so it passes now and i made it check-pass. lmk if i'm missing why it should still be rejected.
…k, r=saethlin add `-Zforce-intrinsic-fallback` flag Add a flag that forces the use of the fallback body (if one exists), so that we can test that these fallback implementations actually work. cc rust-lang#150946 cc [#t-compiler > testing intrinsic fallback bodies](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/testing.20intrinsic.20fallback.20bodies/with/606299558)
…r=petrochenkov delegation: refactor AST -> HIR lowering After a lot of new features were added to delegation the code became a bit worse, as resolution and lowering logic is mixed in `delegation.rs`. In this file the output of resolution step of delegation is transferred as function params (in some functions up to 7 or 8 params), which is not good looking for me. As I mentioned in the previous paragraph delegation AST -> HIR lowering can be split into two phases: 1. Resolution - we collect all information about signature, signature parent context, delegation parent, delegation generics. Then this information is used in AST -> HIR lowering, 2. AST -> HIR lowering - we generate everything based on the output of resolution. This PR explicitly splits those two phases: as a first step we collect all needed information into `DelegationResolution` struct and then use it during AST -> HIR lowering. The `delegation.rs` file is moved into `delegation` folder and renamed to `mod.rs`, the final file structure is as follows: - `mod.rs` - contains lowering logic for everything but generics, - `generics.rs` - contains logic for resolution and uplifting of generic params, placed in a separate file as it is a significant and independent part of lowering, - `attributes.rs` - contains relatively small piece of logic which connects to attributes inheritance, - `resolution.rs` - contains logic for resolution of everything but generics. As resolution of delegation and generics logically does not depend on `LoweringContext`, as from its name `LoweringContext` contains many additional information which is used for lowering, I've created `LoweringContextForResolution` trait which abstracts operations which are used during delegation resolution. Benefits of this PR: - Resolution information is grouped into single struct, is extracted from AST -> HIR lowering which leads to better transfer of resolution across lowering (through a single struct, not through many arguments) and enhanced understanding of which information we use for delegation lowering, - There is now a single path for generating error delegation - if an error was returned from delegation resolution, - Refactorings of `uplift_delegation_generics` which was creating generic params for delegation made the code more understandable. Part of rust-lang#118212. r? @petrochenkov
…y789,davidtwco make some tidy errors around python easier to understand someone i was helping hit a tidy python formatting error in CI, tried to run the exact `tidy` command that bootstrap printed as an error, got *another* error because rustc isn't installed globally, only locally, and then gave up in frustration because they couldn't tell what tidy even wanted them to fix. make some targeted improvements. i'm not sure why diffs were disabled by default before. it's been like that ever since python formatting was originally added in rust-lang#112482, with no explanation. i think showing the diff is a better default. before: ``` $ ./x t tidy --extra-checks=py:fmt checking python file formatting Would reformat: ferrocene/ci/scripts/calculate_parameters.py 1 file would be reformatted, 118 files already formatted rerun tidy with `--extra-checks=py:fmt --bless` to reformat Python code tidy [extra_checks:python_fmt]: checks with external tool 'ruff' failed tidy [extra_checks:python_fmt]: FAIL tidy: The following check failed: extra_checks:python_fmt Command `/home/ci/project/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/home/ci/project --cargo-path=/home/ci/project/build/x86_64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/home/ci/project/build --concurrency=4 --npm-path=yarn --extra-checks=py:fmt` failed with exit code 1 Created at: src/bootstrap/src/core/build_steps/tool.rs:1630:23 Executed at: src/bootstrap/src/core/build_steps/test.rs:1533:29 Command has failed. Rerun with -v to see more details. Build completed unsuccessfully in 0:00:55 $ /home/ci/project/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/home/ci/project --cargo-path=/home/ci/project/build/x86_64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/home/ci/project/build --concurrency=4 --npm-path=yarn --extra-checks=py:fmt --bless tidy [CI history]: no base commit found. Some checks will be skipped. thread 'deps (.)' (25771) panicked at src/tools/tidy/src/deps.rs:700:20: cmd.exec() failed with `cargo metadata` exited with an error: error: could not execute process `rustc -vV` (never executed) Caused by: No such file or directory (os error 2) note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' (25768) panicked at src/tools/tidy/src/main.rs:53:61: called `Result::unwrap()` on an `Err` value: Any { .. } ``` after: ``` checking python file formatting Would reformat: ferrocene/doc/specification/make.py 1 file would be reformatted, 118 files already formatted python formatting does not match! Printing diff: --- ferrocene/doc/specification/make.py +++ ferrocene/doc/specification/make.py @@ -64,6 +64,7 @@ return dest / builder + def build_linkchecker(root): repo = root / ".linkchecker" src = repo / "src" / "tools" / "linkchecker" 1 file would be reformatted, 118 files already formatted rerun with `--bless` to reformat Python code: `./x.py test tidy --extra-checks=py:fmt --bless` ``` ``` thread 'deps (.)' (249572429) panicked at src/tools/tidy/src/deps.rs:696:9: tidy must be run under bootstrap (./x test tidy), not as a standalone command note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ```
…ath, r=JohnTitor borrowck: Introduce BlameConstraint::to_obligation_cause_from_path() Before this commit, `BlameConstraint` is a bit hard to understand at first, because of its `ObligationCause` field. In practice, `BlameConstraint` is just a slimmed down version of an `OutlivesConstraint` from `Vec<OutlivesConstraint>`. The artificial `ObligationCause` is only needed in one place. Rather than having that exception polute the lower level logic, bubble it up as much as we can. That way, it becomes clearer what `BlameConstraint` actually is. For reference, `ObligationCause` was introdued by rust-lang#89249, but the codebase looked quite different back then. This takes us one step closer (this is commit 1 of 4) towards the end result illustrated in rust-lang#158623. # Notes I have removed the comment ```rs // We try to avoid reporting a `ConstraintCategory::Predicate` as our best constraint. // Instead, we use it to produce an improved `ObligationCauseCode`. ```` because I think [this](https://github.com/rust-lang/rust/blob/e2af9c03ef4cfb769e391968a5cfbb1afe6f01e2/compiler/rustc_borrowck/src/region_infer/mod.rs#L1763-L1762) existing comment is sufficient: ```rs // We handle predicates and opaque types specially; don't prioritize them here. ConstraintCategory::Predicate(_) | ConstraintCategory::OpaqueType => 4, ```
…=aapoalas Optimize `ArrayChunks::try_rfold` with `DoubleEndedIterator::next_chunk_back` Since `DoubleEndedIterator::next_chunk_back` got merged in rust-lang#156737, we can apply this method to optimize `ArrayChunk::try_rfold`. I added @vinDelphini as a co-author because he was the one who originally made this change in his original PR on introducing [`DoubleEndedIterator::next_chunk_back`](rust-lang#151668).
…sketchy, r=Darksonn library: Comment on libtest's dicey internal soundness This is the sort of thing that technically violates safety constraints but the requirements for hitting it are "write a custom test harness and call into an env-inspecting part of libc", which seems specific enough that we have no real reason to "fix" it. However, a safety comment seems warranted.
…its, r=clarfonthey Move `SizeHint` and `IoHandle` to `core::io` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Split From: rust-lang#156527 ## Description Move both of these internal IO traits to `core::io`. Since these are already unstable this is just a simple move with no observable changes. --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see rust-lang#154046 (comment) for a review order and broader context for this PR.
…, r=lcnr refactor the normalization in `coerce_shared_info` This is pre-requisite of removing `eq_structurally_relating_aliases` which is part of rust-lang#155345. `coerce_shared_info` is only used in the unstable feature `reborrow` which provides a `CoerceShared` trait indicating a mutable borrow can be converted into a shared borrow. I think using `deeply_normalize` is more suitable for these identity instantiated types. No reason to allow ambiguous normalization and use infer vars as normalization result here. r? lcnr
…olve, r=petrochenkov
resolver: don't use `Finalize` when resolving visibilities during AST expansion
During AST expansion we need to resolve visibilities of items. It uses `Finalize` to make sure to get a definite result on the resolution (a sort of hacky way). this pr disables the use of `Finalize` as it contradicts the invariant proposed by it:
```rust
/// Invariant: if `Finalize` is used, expansion and import resolution must be complete.
struct Finalize { ... }
```
Update TypeVisitable implementation r? oli-obk `TypeVisitable` had some redundant/specific implementations which I've generalized and extended to be a little more broad. Boxed slices now derive their impl from `Box<T>` and `[T]` (instead of `Box<[T]>`), and an implementation for fixed-size arrays was added cuz [I needed that](https://github.com/rust-lang/rust/pull/158632/changes#diff-f1c6da80803e15c8bca78842a05972878a299c2b375dab82635e1124cd0ce08fR539). Also removed `Sized` restrictions on `&T` and `Box<T>` to make it all work. Could probably stand to do the same for some other types, but that wasn't necessary for my changes.
Tweaks to MIR building scope API Some simplifications that come from staring too long at that code
rustbot
added
A-CI
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 3, 2026
Rollup of 18 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-2
Contributor
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
19 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:
IntoIteratorfor[&[mut]] Box<[T; N], A>#134021 (ImplementIntoIteratorfor[&[mut]] Box<[T; N], A>)without_debuginfotest frombacktrace-rsto the testsuite #152860 (Port thewithout_debuginfotest frombacktrace-rsto the testsuite)-Zforce-intrinsic-fallbackflag #158377 (add-Zforce-intrinsic-fallbackflag)ArrayChunks::try_rfoldwithDoubleEndedIterator::next_chunk_back#158704 (OptimizeArrayChunks::try_rfoldwithDoubleEndedIterator::next_chunk_back)SizeHintandIoHandletocore::io#158539 (MoveSizeHintandIoHandletocore::io)coerce_shared_info#158659 (refactor the normalization incoerce_shared_info)Finalizewhen resolving visibilities during AST expansion #158689 (resolver: don't useFinalizewhen resolving visibilities during AST expansion)r? @ghost
Create a similar rollup