Rustc pull update#2905
Merged
Merged
Conversation
Add experimental `unnamed_enum_variants` feature gate This parses the basic syntax and defines a feature gate for the unnamed enum variants lang experiment, tracking issue rust-lang/rust#156628. cc @joshtriplett, @scottmcm, @tmandry
tests: codegen-llvm: Update bpf-alu32 with the new LLVM attributes The LLVM backend now emits `noundef zeroext` on `i8` return values and `noundef` on `i8` parameters. Update the FileCheck pattern to match. r? @nagisa
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to e99720b. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…uwer Rollup of 5 pull requests Successful merges: - rust-lang/rust#154586 (Record failed tests with `--record`, and rerun them with `--rerun`) - rust-lang/rust#157296 (delegation: split resolution and lowering) - rust-lang/rust#156171 (Fix a coroutine UI test which is missing `#[coroutine]`) - rust-lang/rust#157249 (tests: codegen-llvm: Update bpf-alu32 with the new LLVM attributes) - rust-lang/rust#157426 (rustc-dev-guide subtree update)
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
Eagerly decide whether relaxed bounds are allowed or not r? @davidtwco or @fmease Previously introduced in rust-lang/rust#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/rust#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.
…infer-ice, r=lcnr Don't ICE in has_self_borrows when coroutine captures-by-ref ty is still inferred Closes rust-lang/rust#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.
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/rust#152287, which was reverted in rust-lang/rust#152738 as it had exposed another underlying unsoundness (rust-lang/rust#153596, exhibited indirectly in rust-lang/rust#152735), which was recently fixed in rust-lang/rust#155749. It’s the same fix and the same set of tests. Regression tests for the unsoundness itself were already added in rust-lang/rust#155749. Closes rust-lang/rust#137190. Closes rust-lang/rust#135470.
…ilities, 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/rust#156538
r? @lcnr
…uwer Rollup of 8 pull requests Successful merges: - rust-lang/rust#156281 (Emit nofree attribute) - rust-lang/rust#157305 (Eagerly decide whether relaxed bounds are allowed or not) - rust-lang/rust#148713 (rustc_borrowck: fix async closure error note to report AsyncFn rather than Fn) - rust-lang/rust#156266 (Don't ICE in has_self_borrows when coroutine captures-by-ref ty is still inferred) - rust-lang/rust#156417 (Fix an ICE in the vtable iteration for a trait reference in const eval when a supertrait is not implemented) - rust-lang/rust#156956 (Support generic params in `Lift_Generic`) - rust-lang/rust#157140 ( rustc_target: Use rustc_abi instead of cfg_abi to detect powerpcspe ) - rust-lang/rust#157423 (Refactor/expand rustc_attr_parsing docs)
Windows TLS: avoid atexit call in Miri This was added in rust-lang/rust#148799. I did not realize that we're actually falsely pretending that `atexit` worked, I thought we'd always return an error. Having it pretend to work when really it did nothing seems like a bad idea so let's just skip that call under `cfg(miri)`. r? @ChrisDenton Cc @ohadravid
Avoid loading HIR for check_well_formed on type declarations r? @compiler-errors
…=jhpratt Optimize `checked_ilog` and `pow` when `base` is a power of two Optimize `checked_ilog` and `pow` when the base is a power of two
…d-for-pattern, r=Mark-Simulacrum perf: use `get_unchecked` for `TwoWaySearcher` ## What is this PR? *This is related to rust-lang/rust#27721.* This PR is a proposal for a performance improvement in `std::pattern`. Profiling of [https://github.com/quickwit-oss/quickwit](https://github.com/quickwit-oss/quickwit) in production shows that `TwoWaySearcher::next` is one of the most CPU-time-consuming functions, so I thought I would give it a look. I read the [contribution guide](https://std-dev-guide.rust-lang.org/development/perf-benchmarking.html) and this seems to be a fitting proposal. It seems like `TwoWaySearcher::next` and `TwoWaySearcher::next_back` could be made faster by using `get_unchecked` in the inner loop comparisons instead of regular indexing, which is safe in the conditions where it would be done (indices are within bounds by construction). I added some `SAFETY` comments in the code to explain why this is safe, as I believe is customary in those cases (and according to [this page as well](https://std-dev-guide.rust-lang.org/policy/safety-comments.html)). ### Benchmarks I ran the existing bencharmks before/after the changes (only on my laptop, I can run them in other places if that's necessary). ``` ./x.py bench library/coretests -- pattern:: ``` We seem to be getting a ~7.5-12% performance improvement at a very low cost, which sounds worthwhile to me. But this is the first time I'm proposing a change in Rust, so I'm looking forward to feedback on this. ``` BEFORE CHANGES pattern::ends_with_char 3398.91ns/iter +/- 526.28 pattern::ends_with_str 3545.04ns/iter +/- 1108.76 pattern::starts_with_char 3348.31ns/iter +/- 352.38 pattern::starts_with_str 3710.59ns/iter +/- 435.57 AFTER CHANGES pattern::ends_with_char 3125.99ns/iter +/- 567.09 (-8.03%) pattern::ends_with_str 3106.43ns/iter +/- 258.33 (-12.38%) pattern::starts_with_char 3094.55ns/iter +/- 595.42 (-7.59%) pattern::starts_with_str 3365.75ns/iter +/- 268.88 (-9.29%) ``` System info for the benchmarks run <details> ``` Based on commit 8317fef20409adedaa7c385fa6e954867bf626fc rustc 1.96.0-dev binary: rustc commit-hash: unknown commit-date: unknown host: aarch64-apple-darwin release: 1.96.0-dev LLVM version: 22.1.2 Apple M4 Max 16 64 GB ProductName: macOS ProductVersion: 26.3 BuildVersion: 25D125 (this was run on AC and without any heavy load from other apps or whatnot) ``` </details>
…r=BoxyUwU remove UnevaluatedConstKind::def_id this is some of the const side of rust-lang/rust#152245 not quite a _full_ removal, there's still some spicy things such as `UnevaluatedConstKind::def_span` remaining that won't quite work for new non-DefID `UnevaluatedConstKind` cases, but IMO this is the bulk of the work, and feature-specific things can deal with their quirks in their own PRs when they know their own use cases. r? @BoxyUwU self-reminder: file an issue on what to do about rustc_public's handling of the raw DefIds in rustc_public AliasTy/AliasConst
…rochenkov Rewrite `rustc_span::symbol::Interner` to avoid double hashing Involves resorting to raw `HashTable` and writing an ad-hoc `IndexMap`-like structure, as we cannot get access to raw hashes otherwise. My local cachegrind profile shows ~ -20_000_000 Ir r? @petrochenkov
Make trait refs & assoc ty paths properly induce trait object lifetime defaults ## Trait Object Lifetime Defaults ### Primer & Definitions You could read [this section](https://doc.rust-lang.org/reference/lifetime-elision.html#default-trait-object-lifetimes) in the Reference but it has several issues (see rust-lang/reference#1407). Here's a small explainer by me that only mentions the parts relevant to this PR: Basically, given `dyn Trait` (≠ `dyn Trait + '_`) we want to deduce its *trait object lifetime bound* from context without relying on normal region inference as we might not be in a body[^1]. The "context" means the closest – what I call – *(eligible) container* `C<X0, …, Xn>` that wraps this trait object type. A *container* is to be understood as a use site of a "parametrized definition" (more general than type constructors). Currently *eligible* are ADTs, type aliases, traits and enum variants. So if we have `C<dyn Trait>` (e.g., `&'r dyn Trait` or `Struct<'r, dyn Trait>`), `D<C<dyn Trait>>` or `C<N<dyn Trait>>` (e.g., `Struct<'r, (dyn Trait,)>`), we use the explicit[^2] outlives-bounds on the corresponding type parameter of `C` to determine the trait object lifetime bound. Here, `C` & `D` denote (eligible) containers and `N` denotes a generic type that is **not** an eligible container. E.g., given `struct Struct<'a, T: 'a + ?Sized>(…);`, we elaborate `Struct<'r, dyn Trait>` to `Struct<'r, dyn Trait + 'r>`. Finally, we call lifetime bounds used as the default for *constituent* trait object types of an eligible container `C` the *trait object lifetime defaults* (*induced by* `C`). These defaults may of course end up getting shadowed in parts of the type by the defaults induced by any inner eligible containers. ### Changes Made **These changes are theoretically breaking**. 1. Make *resolved* associated type paths / projections eligible containers. * `<Y0 as TraitRef<X0, …, Xn>>::AssocTy<Y1, …, Ym>` now induces *trait object lifetime defaults* for constituents `Y0` to `Ym` (`TraitRef` is considered a separate container, see also list item **(3)**). * Notably, for the self type `Y0` of (resolved) projections we now look at the bounds on the `Self` type param of the relevant trait (e.g., given `trait Outer<'a>: 'a { type Proj; }` or `trait Outer<'a> where Self: 'a { type Proj; }` we elaborate `<dyn Inner as Outer<'r>>::Proj` to `<dyn Inner + 'r as Outer<'r>>::Proj`). * Example breakages: ```rs trait Outer<'a> { type Ty<T: ?Sized + 'a>; } impl<'a> Outer<'a> for () { type Ty<T: ?Sized + 'a> = &'a T; } trait Inner {} fn f<'r>(x: <() as Outer<'r>>::Ty<dyn Inner>) { // ~~~~~~~~~ // this branch: dyn Inner + 'r (due to bound `'a` on `T`) // stable/main: dyn Inner + 'static (due to item signature fallback) let _: <() as Outer<'r>>::Ty<dyn Inner + 'static> = x; // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // this branch: error: lifetime may not live long enough // `'r` must outlive `'static` // stable/main: OK } ``` ```rs trait Outer { type Ty; } trait Inner {} impl<'a> Outer for dyn Inner + 'a { type Ty = &'a (); } fn f<'r>(x: *mut &'r <dyn Inner as Outer>::Ty) { // ~~~~~~~~~ // this branch: dyn Inner + 'static (due to lack of bounds on `Outer`; the assoc type path shadows the default induced by the type ctor `&`) // stable/main: dyn Inner + 'r (due to bound `'a` on `T` in (pseudo) `builtin type &<'a, T: 'a + ?Sized>;`) let _: *mut &'r <dyn Inner + 'r as Outer>::Ty = x; // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // this branch: error: lifetime may not live long enough // `'r` must outlive `'static` // stable/main: OK } ``` 2. In *type-relative* paths `Y0::Name<Y1, …, Ym>` consider the trait object lifetime default **indeterminate** * Meaning if we're in an "item context" / "item signature" / "non-body" (& the principal trait isn't bounded by any outlives-bounds which would take precedence over the default) we will **reject** any implicit trait object lifetime bounds that would take on that default * Reason: Limitations of the current implementation which can't be easily overcome * RBV (which resolves trait object lifetime defaults by recursing into the local crate "in one sitting") would require the resolution of *type-relative* paths in order to look up the generics but these paths are only resolved in HIR ty lowering (that can selectively lower local items) which depends on the results of RBV (cyclic dependency!) * While one might be able to resolve type-relative paths in RBV in an ad-hoc fashion, it would require a lot of duplication with HIR ty lowering and its impl would be very brittle (RTN does something like that in RBV but we require a more sophisticated resolver) * I did attempt that but it got too gnarly and brittle and would've likely been incomplete anyway * See also [this GH thread](rust-lang/rust#129543 (comment)) * See also [#t-types/meetings > 2025-09-16 weekly @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326132-t-types.2Fmeetings/topic/2025-09-16.20weekly/near/539889059) * This should still be maximally forward compatible and allow us to implement the desired behavior in the future. * Example breakage: ```rs trait Outer { type Ty<'a, T: 'a + ?Sized>; } trait Inner {} fn f<'r, T: Outer>(x: T::Ty<'r, dyn Inner>) {} // ~~~~~~~~~ // this branch: error: indeterminate (reservation) // stable/main: dyn Inner + 'static (due to item signature fallback) ``` 3. Fixes trait object lifetime defaults inside trait refs `TraitRef<X0, …, Xn>` (this fell out from the previous changes). They used to be completely broken due to a nasty off-by-one error for not accounting for the implicit `Self` type param of traits which lead to cases like * `Outer<'r, dyn Inner>` (with `trait Outer<'a, T: 'a + ?Sized> {}`) getting rejected as *indeterminate* (it tries to access a *lifetime* at index 1 instead 0) ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=0069c89b2313f0f447ff8b6f7de9adfa)) * `Outer<'r, 's, dyn Inner>` (with `trait Outer<'a, 'b, T: 'a + ?Sized> {}`) elaborating `dyn Inner` to `dyn Inner + 's` instead of `dyn Inner + 'r`(!) which subsequently gets rejected of course since `'s` isn't known to outlive `'r` ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9c521165e0ac0d868a8087cd7ca861fe)) * The same applies to trait *alias* refs (feature `trait_alias`) * Example breakage: ```rs trait Outer<'a, 'b, T: 'a + ?Sized> {} trait Inner {} struct F<'r, T> where T: Outer<'r, 'static, dyn Inner> // ~~~~~~~~~ // this branch: dyn Inner + 'r (correctly mapping `'a` => `'r`) // stable/main: dyn Inner + 'static (incorrectly mapping `'a` => `'static` due to off-by-one) { g: G<'r, T>, // ~~~~~~~~ // this branch: error: mismatched types // expected: `Outer<'r, 'static, (dyn Inner + 'static)>` // found: `Outer<'r, 'static, (dyn Inner + 'r)>` // stable/main: OK } struct G<'r, T>(&'r (), T) where T: Outer<'r, 'static, dyn Inner + 'static>; ``` 4. In associated type binding `TraitRef<AssocTy<X0, …, Xn> = Y>` consider the trait object lifetime default **indeterminate** (in `X0`, …, `Xn` and `Y`) if `X0`, …, `Xn` contains any lifetime arguments. * Meaning if we're in an item context (& the principal trait isn't bounded) we will **reject** any implicit trait object lifetime bounds that would take on that default * This reserves us the right to (1) take into account the *item bounds* of `AssocTy` in the future when computing the default for `Y` (2) take into account the parameter bounds of `AssocTy` in the future when computing the defaults for `X0`, …, `Xn`. * This extends a preexisting hack that – given `TraitRef<X0, …, Xn, AssocTy<Y0, …, Ym> = Z>` – treats the default indeterminate in `Y0`, …, `Ym` and `Z` if `X0`, …, `Xn` contains any lifetime arguments. * Rephrased, this hack / reservation previously didn't account for GAT args, only trait ref args, which is insufficient * See also [this GH comment of mine](rust-lang/rust#115379 (comment)) * Example breakages: ```rs trait Outer { type Ty<'a>: ?Sized; } trait Inner {} fn f<'r>(_: impl Outer<Ty<'r> = dyn Inner>) {} // ~~~~~~~~~ // this branch: error: indeterminate (reservation) // stable/main: dyn Inner + 'static (forced) ``` ```rs trait Outer { type Ty<'a, T: ?Sized + 'a>; } trait Inner {} fn f<'r>(_: impl Outer<Ty<'r, dyn Inner> = ()>) {} // ~~~~~~~~~ // this branch: error: indeterminate (reservation) // stable/main: dyn Inner + 'static (forced) ``` #### Motivation Both trait object lifetime default RFCs ([599](https://rust-lang.github.io/rfcs/0599-default-object-bound.html) and [1156](https://rust-lang.github.io/rfcs/1156-adjust-default-object-bounds.html)) never explicitly specify what constitutes a — what I call — *(eligible) container* but it only makes sense to include anything that can be parametrized by generics and can be mentioned in places where we don't perform full region inference … like associated types. So it's only *consistent* to make this change. #### Breakages **These changes are theoretically breaking** because they can lead to different trait object lifetime bounds getting deduced compared to main which is obviously user observable. Moreover, we're now explicitly rejecting implicit trait object lifetime bounds inside type-relative paths (excl. the self type) and on the RHS of assoc type bindings if the assoc type has lifetime params. However, the latest crater run found 0 non-spurious regressions (see [here](rust-lang/rust#129543 (comment)) and [here](rust-lang/rust#129543 (comment))). --- Fixes rust-lang/rust#115379. Fixes rust-lang/rust#140710. Fixes rust-lang/rust#141997. [^1]: If we *are* in a body we do use to normal region inference as a fallback. [^2]: Indeed, we don't consider implied bounds (inferred outlives-bounds).
Set !captures metadata for store of &Freeze
When a `&Freeze` reference is stored (with retag), emit `!captures !{!"address", !"read_provenance"}` metadata to indicate that it's UB to write through the stored pointer.
Related to rust-lang/rust#146844.
r? @ghost
…illot Build the dep-graph reverse index lazily, per DepKind Replace the eager per-DepKind fingerprint-to-index map built at decode with a counting sort into per-kind ranges plus a lazily-built map per kind.
Add a check for impossible predicates to trivial_const The problem here is that trivial consts bypass the MIR pass which replaces bodies with `unreachable` when there are false global bounds. see rust-lang/rust#147721 (comment). This fixes the problem, but it is a bit hacky. But maybe all the handling of false global bounds is hacky?
Add `#[rustc_dump_generics]` attribute Added a rustc attribute to dump the generic parameters of a given item to the compiler output.
This updates the rust-version file to 8c75e93c5c7671c29f3e8c096b7acf56822ed23a.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@8c75e93 Filtered ref: a36415b Upstream diff: rust-lang/rust@49b19d3...8c75e93 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
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
4 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.
Latest update from rustc.