Rollup of 8 pull requests#157440
Merged
Merged
Conversation
…l when a supertrait not implemented compiler/rustc_trait_selection/src/traits/vtable.rs@`vtable_entries`: The impossible predicates check in `vtable_entries` used `instantiate_own` which only includes the method's own where-clauses, not the parent trait's bounds. Replace it with `instantiate_and_check_impossible_predicates` which also checks the trait ref itself, so unsatisfied supertrait bounds are caught and the method is marked `Vacant` instead of ICEing.
Upvar inference unconditionally unifies `tupled_upvars_ty` (via
`demand_suptype` near the bottom of `analyze_closure`), but skipped
unifying `coroutine_captures_by_ref_ty` whenever the closure args
already referenced an error. That left the captures-by-ref inference
variable unconstrained for tainted coroutine-closures, breaking the
invariant `has_self_borrows` relies on (`FnPtr` or `Error`).
If the body contains an unresolved `as _` cast, e.g.
```rust
//@ edition:2021
fn needs_fn_mut<T>(x: impl FnMut() -> T) {
needs_fn_mut(async || x as _)
}
```
selection later reaches `has_self_borrows` and trips its
`_ => panic!()` arm.
Always equate `coroutine_captures_by_ref_ty` in the error path -- to
`Ty::new_error(guar)` -- so the invariant holds and downstream
consumers can rely on the inference variable being resolved.
… so we still collect generic bounds from the type
Treat the semantics of pointee.size as "dereferenceable-at-point" and always specify the size. Instead, use a separate NoFree attribute to determine whether dereferenceability extends to the whole function. Then in the LLVM backend, only actually emit dereferenceable if nofree is also set, as dereferenceable currently implies nofree. In addition, explicitly emit the nofree attribute, which will help when LLVM switches dereferenceable to be at-point.
Emit nofree attribute Treat the semantics of pointee.size as "dereferenceable-at-point" and always specify the size. Instead, use a separate NoFree attribute to determine whether dereferenceability extends to the whole function. Then in the LLVM backend, only actually emit dereferenceable if nofree is also set, as dereferenceable currently implies nofree. In addition, explicitly emit the nofree attribute, which will help when LLVM switches dereferenceable to be at-point. Relevant recent LLVM PR: llvm/llvm-project#195658
…ease Eagerly decide whether relaxed bounds are allowed or not r? @davidtwco or @fmease Previously introduced in rust-lang#142693 by @fmease I am trying to resolve https://github.com/rust-lang/rust/blob/d7986943e496ccb07987f4ad83c6f7033d725861/compiler/rustc_hir_analysis/src/hir_ty_lowering/bounds.rs#L196, but then got into a rabbit hole somehwere. I think this PR further unblocks resolving that FIXME, because it makes it easier to reason about whether we should be reporting an error about duplicate bounds or about relaxed bounds in general
rustc_borrowck: fix async closure error note to report AsyncFn rather than Fn Fixes rust-lang#148391 Root cause: `async` closures are treated like plain `Fn` closures because we never updated their kind after adding the async coroutine path. Symptom: The compiler note tells users `closure implements Fn…`, which is wrong for async closures and made the error message confusing. Notably `FnMut` does not suffer from this issue. Fix: Fixed the wording Testing: Updated a UI test stderr file to reflect the correct wording. It also clearly demonstrates what was wrong.
…captures-infer-ice, r=lcnr Don't ICE in has_self_borrows when coroutine captures-by-ref ty is still inferred Closes rust-lang#155999. `coroutine_captures_by_ref_ty` is a fresh `next_ty_var` until upvar inference unifies it to an `FnPtr`. If `has_self_borrows` is reached before that — e.g. when the body contains an unresolved `as _` cast — the `_ => panic!()` arm fires: ```rust //@ edition:2021 fn needs_fn_mut<T>(x: impl FnMut() -> T) { needs_fn_mut(async || x as _) } ``` Treat the `Infer` case like `Error`: report self-borrows defensively so the closure falls back to `FnOnce`-only and the caller surfaces a normal type-inference error instead of an ICE.
… r=lcnr Fix an ICE in the vtable iteration for a trait reference in const eval when a supertrait is not implemented This is a second incarnation of rust-lang#152287, which was reverted in rust-lang#152738 as it had exposed another underlying unsoundness (rust-lang#153596, exhibited indirectly in rust-lang#152735), which was recently fixed in rust-lang#155749. It’s the same fix and the same set of tests. Regression tests for the unsoundness itself were already added in rust-lang#155749. Closes rust-lang#137190. Closes rust-lang#135470.
…ric-capabilities, r=lcnr
Support generic params in `Lift_Generic`
Handle generic type parameters, including nested occurrences, when deriving `Lift_Generic`.
This lets types like `Binder<I, T>` use `#[derive(Lift_Generic)]` instead of requiring a manual `Lift` impl.
Concretely it can now handle structs as follows;
```rs
// Generic type parameter
struct Binder<I: Interner, T> {
// body
}
// Nested generic type parameter
pub struct Binder<I: Interner, T = SomeKind<I>> {
//
}
```
Split off from the `Alias` refactor work; rust-lang#156538
r? @lcnr
rustc_target: Use rustc_abi instead of cfg_abi to detect powerpcspe When self-reviewing rust-lang#157137, I recalled a previous my comment (rust-lang#153876 (comment)) about a case where cfg_abi is referred but rustc_abi should be referred. > There is another powerpc code that [refers to `abi` field](https://github.com/rust-lang/rust/blob/bfc05d6b072585dfd0c792ec1b8728c08a3511fe/compiler/rustc_target/src/asm/powerpc.rs#L125), but it should be changed to refer to the target feature. `tests/codegen-llvm/asm/powerpc-clobbers.rs` contains a test to check whether this detection is working properly: https://github.com/rust-lang/rust/blob/6368fd52cb9f230dfb156097625993e7a8891800/tests/codegen-llvm/asm/powerpc-clobbers.rs#L123 r? @RalfJung @rustbot label +O-PowerPC +A-target-feature
…onathanBrouwer Refactor/expand rustc_attr_parsing docs
rustbot
added
A-attributes
Contributor
Author
Contributor
rust-bors
Bot
added
the
S-waiting-on-bors
rust-bors
Bot
removed
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jun 4, 2026
Rollup of 8 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
This comment has been minimized.
This comment has been minimized.
Contributor
rust-bors
Bot
added
merged-by-bors
Contributor
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: b3f7e32046 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 b3f7e32 (parent) -> 688ab44 (this PR) Test differencesShow 94 test diffsStage 1
Stage 2
Additionally, 80 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 688ab44c7439a226d792990f81cd8df0603747d8 --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 |
This was referenced Jun 4, 2026
Collaborator
|
Finished benchmarking commit (688ab44): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@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 -1.1%, secondary 1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -3.5%, secondary -3.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 512.944s -> 515.112s (0.42%) |
Contributor
Author
|
Started perf jobs |
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
11 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:
Lift_Generic#156956 (Support generic params inLift_Generic)r? @ghost
Create a similar rollup