Rustc pull update#2168
Merged
Merged
Conversation
…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
…seZ4 Link LLVM dynamically on x86_64-apple Link LLVM dynamically on x86_64-apple just like we did for aarch64-apple-darwin * rust-lang/rust#157205 r? @ZuseZ4
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?
… r=dingxiangfei2009 Handle generic reborrow in expression-use adjustment walking Fixes an ICE in expression-use adjustment walking where `Adjust::GenericReborrow` could reach a match arm that assumed generic reborrow was unreachable. `GenericReborrow` is already emitted by typeck and classified as rvalue-producing elsewhere in `expr_use_visitor.rs`, so the adjustment walker must handle it explicitly instead of panicking. This PR models `GenericReborrow` as a borrow-like use of the source expression: - `Mutability::Mut` is treated like an exclusive/mutable reborrow use. - `Mutability::Not` is treated like a shared/coerce-shared borrow-like use. - The source is not moved or treated as a mere copy. cc @aapoalas @rustbot label F-reborrow Fixes rust-lang/rust#156339 Tracking: rust-lang/rust#145612
Reject `impl const Trait` since the right syntax is `const impl Trait` now I also let some smaller rustfmting of ui tests through, as rustfmt immediately formats `impl const Trait` to `const impl Trait`. This is also the reason I expect that this change will break very little nightly users, so we don't even need to add some helpful diagnostic. r? @fee1-dead
…rce-unsafety, r=dingxiangfei2009 Fix reborrow source expression visits Fixes rust-lang/rust#158033
Bump thin-vec to 0.2.18 to address RUSTSEC-2026-0103 thin-vec versions before 0.2.16 have a use-after-free / double-free in `IntoIter::drop` and `ThinVec::clear` when an element's `Drop` panics ([RUSTSEC-2026-0103](https://rustsec.org/advisories/RUSTSEC-2026-0103)). This bumps the requirement in the compiler crates from `0.2.15` to `0.2.18` and updates `Cargo.lock` accordingly, moving past the affected range.
…Darksonn Document transient connection errors from TcpListener::accept `TcpListener::accept` can return an error that belongs to a single incoming connection, not to the listener, for example a connection aborted by the peer before it could be accepted (`ConnectionAborted`). The listener stays usable, so a server looping over connections usually wants to log the error and keep accepting rather than treat it as fatal. This was not documented, and the `incoming` example treated every error as a failed connection. This implements the libs-team decision in rust-lang/rust#142557: document these transient errors instead of changing `accept` to retry them, since retrying would hide errors that some callers want to observe. Changes: - Add an `# Errors` section to `accept` describing this behavior, without listing specific error codes since some may be more permanent than others. - Note that `Interrupted` errors are retried internally on Unix. - Add the same pointer to `incoming` and `into_incoming`, which are `accept` in a loop. Addresses rust-lang/rust#142557. r? rust-lang/libs
rustdoc-json-types: Replace bincode dev-dependency with postcard bincode is flagged as unmaintained by [RUSTSEC-2025-0141](https://rustsec.org/advisories/RUSTSEC-2025-0141), and the advisory covers the entire crate with no patched version available. The only use in `rustdoc-json-types` was the binary serde roundtrip in the type tests. [postcard](https://crates.io/crates/postcard) is a maintained serde-based binary serialization format that covers the same roundtrip testing need. bincode is still pulled in transitively by the miri subtree (via `ipc-channel`), which needs to be [addressed upstream](rust-lang/miri#5115). ### Related - rust-lang/miri#5115
renovate: Loosen dashboard approval and adopt recommended config Follow-up tweaks to the Renovate config now that the GitHub Actions setup has proven stable. - GitHub Actions updates no longer need Dependency Dashboard approval. The gate was added while we dialed in the config, and the `github-actions` manager now works well enough for those PRs to open on their own. Everything else still requires approval. - Monthly lock file maintenance is now enabled. It stays behind dashboard approval for the time being. - The config extends [`config:recommended`](https://docs.renovatebot.com/presets-config/#configrecommended), which brings changelog links, sensible grouping, `replacements` and `workarounds`. That makes the previously explicit `dependencyDashboard: true` redundant, so it's gone. - Config migration PRs are enabled so Renovate can keep the config up to date as options get deprecated.
… r=lqd codegen_ssa: no dbginfo for scalable vec local w/ `-O0` LLVM uses GlobalISel with `-O0` that doesn't support scalable vectors. It normally falls back to SDAG which does support scalable vectors, but there's a bug that means that isn't happening for debuginfo - so temporarily don't emit debuginfo for scalable vector locals when there are no optimisations until that bug is fixed. cc llvm/llvm-project#204585 cc #2160 r? @lqd
Fix invalid "jump-to-def" doc link generation when an item has a `derive` proc-macro Fixes rust-lang/rust#158050. The problem is that the proc-macros might generate an impl block `impl $(trait)? for Item` where `Item` then has its span pointing to the current item, overwriting its intra-doc link (hopefully this explanation makes sense ^^'). In short, the proc-macro generates an impl block, the `for Item` makes the code enter `visit_qpath` which in turn calls `handle_path` which will take the span of the last segment of the path (so `Item` here) and use it in the link def "span map". r? @Urgau
Rollup of 12 pull requests Successful merges: - rust-lang/rust#156795 (Handle generic reborrow in expression-use adjustment walking) - rust-lang/rust#157694 (Enhance documentation on wake call memory ordering) - rust-lang/rust#157935 (Make `proc_macro::ConversionErrorKind` non exhaustive) - rust-lang/rust#158002 (Replace `unwrap` with `expect` in `get_module_children`) - rust-lang/rust#158009 (Reject `impl const Trait` since the right syntax is `const impl Trait` now) - rust-lang/rust#158034 (Fix reborrow source expression visits) - rust-lang/rust#158072 (Bump thin-vec to 0.2.18 to address RUSTSEC-2026-0103) - rust-lang/rust#158074 (Document transient connection errors from TcpListener::accept) - rust-lang/rust#158077 (rustdoc-json-types: Replace bincode dev-dependency with postcard) - rust-lang/rust#158086 (renovate: Loosen dashboard approval and adopt recommended config) - rust-lang/rust#158088 (codegen_ssa: no dbginfo for scalable vec local w/ `-O0`) - rust-lang/rust#158089 (Fix invalid "jump-to-def" doc link generation when an item has a `derive` proc-macro)
Rollup of 2 pull requests Successful merges: - rust-lang/rust#158026 (`RegionValues`: disable unnecessary range check) - rust-lang/rust#158101 (Initialize directly in `From<T> for OnceLock<T>`)
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 8e150217bafcaaaa0c45bf685c55fd56cec48598.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@8e15021 Filtered ref: bc28f3f Upstream diff: rust-lang/rust@029c9e1...8e15021 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @folkertdev (or someone else) some time within the next two weeks. Why was this reviewer chosen?The reviewer was selected based on:
|
Member
|
r? @davidtwco (I triggered this manually) |
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
6 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.