Rustup - #17751
Merged
Merged
Rustup#17751
Conversation
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@2e2b193 Filtered ref: rust-lang/miri@fa4559e Upstream diff: rust-lang/rust@edc52f8...2e2b193 This merge was created using https://github.com/rust-lang/josh-sync.
- in general replace Infallible with ! in try-adjacent situations (mainly Result<_, !>) - where applicable extend tests to also validate both ! and a custom enum Uninhabited, to avoid unintentional future divergence
Update internal docs & tests to use `!` rather than `Infallible` in relation to `Try`
- Update docs, internal comments and tests to use `!` rather than `Infallible` in `Try` situations.
- Add a custom `enum Uninhabited {}` to specific clippy tests where unintentional future divergence in handling `!` vs other uninhabited types may be a possible concern
Refs:
- Never is ~~meow~~ now rust-lang/rust#155499
- Try: rust-lang/rust#84277 & rust-lang/goals#654
type system const items via direct rhs fixes rust-lang/rust#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU
abby test DSL: AliasTyOutlivesViaEnv fixes rust-lang/project-assumptions-on-binders#32 adds two new features to the testing DSL: - in test bodies, add `where` syntax. This is parsed as a standard where clause (reusing the parser's `parse_where_clause`) and goes through the full lowering machinery for various destructurings and whatnot, and goes through the `register_obligation` pipeline, rather than being directly inserted into constraint storage. - `where` syntax inside of `or {}` is not supported, nor is it supported inside of `expect {}` - in test bodies (including inside `or {}`) as well as inside `expect {}`, parse `AliasTyOutlivesViaEnv` constraints via the syntax `for<> Some::Alias: 'a`. The second one is particularly boilerplate-y, due to needing to hook up a `Binder`, which needs a `HirId` and whatnot (this is `TestBinderBoundTypeConstraint`). Oh well. r? @BoxyUwU
Update `askama` version to `0.16.1` More information about the release [here](https://github.com/askama-rs/askama/releases/tag/v0.16.1). But in short, small cleanups and bugfixes. r? ghost
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@0ed41eb Filtered ref: rust-lang/miri@1f6e2b2 Upstream diff: rust-lang/rust@a69a632...0ed41eb This merge was created using https://github.com/rust-lang/josh-sync.
Rollup of 14 pull requests Successful merges: - rust-lang/rust#162324 (miri subtree update) - rust-lang/rust#162170 (bootstrap: use target's LLVM libdir when cross-compiling) - rust-lang/rust#158312 (Adds support for AArch64 SVE to inline assembly) - rust-lang/rust#159792 (A more readable debug map for IndexMaps) - rust-lang/rust#160745 (make closures act like MaybeDangling) - rust-lang/rust#161263 (break rustc_expand-rustc_middle dependency) - rust-lang/rust#161895 (std::sys::pal::sgx: fix mismatched alloc/free alignment) - rust-lang/rust#161940 (Promote `wasm32-wasip3` to a tier 2 target) - rust-lang/rust#161397 (coverage: Tidy tests and add some new ones) - rust-lang/rust#161616 (Report precondition violation for `<usize as SliceIndex>::get_unchecked` in const-eval) - rust-lang/rust#162248 (Add regression test for unsized const parameter default ICE) - rust-lang/rust#162250 (Fix hashing of span end columns in incremental compilation) - rust-lang/rust#162265 (cargotest: add lockfiles) - rust-lang/rust#162318 (bootstrap: Fix broken path for `./x doc compiler/rustc --open`)
We have `DiagCtxt`, `DiagCtxtInner`, and `DiagCtxtHandle`. They're all necessary, but the method placement is inconsistent. This commit establishes a clearer rule: methods should *not* go on `DiagCtxt` whenever possible. Benefits: - Simpler rule for deciding where to put a method. - `impl Deref for DiagCtxtHandle` can be removed, including its non-standard double-reference `&&'a DiagCtxt` return value. This makes it impossible to accidentally discard a taint target by calling `handle` on a `DiagCtxtHandle`. - Catches some places where we were calling `dcx.handle()` when `dcx` was already a handle.
yeet VisitorExt This existed to stop people from overriding some methods, but `final fn` exists now. It's already being used in std here and there with no problems, so I figure it's fine to use in the compiler.
It's a trait that is used to give `Diag::emit` different return types depending on the `G` in `Diag<'_, G>`. It works, but it's overkill. There are only four different `G` types in practice (`BugAbort`, `FatalAbort`, `ErrorGuaranteed`, and `()`) and having inherent `emit` methods for each of those four concrete `Diag<'_, G>` types is good enough. This commit makes that change. This removes `EmissionGuarantee` trait bounds from many places, which is nice.
Simplify the `G` in `Diag<'a, G>` The `EmissionGuarantee` trait isn't necessary, and just complicates things. Details in individual commits. r? @oli-obk
libtest: never iterate over all tests in `--exact` mode This should help with rust-lang/miri#5013: When running `cargo miri nextest`, nextest spawns one Miri instance for each test of the crate. If the crate has a lot of tests, a non-trivial amount of time is spent in the test harness before it even starts running the test. Turns out almost half that time is spent just making copies of all the `TestDescAndFn`. That seems silly, we have a perfectly fine static array of those sitting around in the code generated by `--test` expansion, let's just use references to that array. So this changes the `TestList` used to represent the unfiltered list of tests to use borrowed rather than owned types. That changes ripples outwards. The entry points used by the `--test` harness remain mostly unchanged (except that I renamed them as the old name did not make sense), but rustdoc has been using the old fully-owned API. Rustdoc has two codepaths, "standalone" and "merged". - For "merged", the fix is easy -- like the `--test` harness, this can just generate a static array full of `StaticTestFn` rather than populating a `Vec` at runtime. - For "standalone", things are more tricky. We need to construct an `&[&TestDescAndFn]`, which requires filling a new vector with references to the entries of an existing `Vec<TestDescAndFn>`. This also fundamentally relies on the support for dynamic test functions in libtest. Those must now always be cloneable, so they are now internally stored in `Arc` and must be `Fn`, not `FnOnce`. So compared to before there's now one more big `Vec` to fill with references to all tests, as well as some `Arc::clone`. OTOH this mode runs a full separate process for each test so I doubt this extra cost is noticeable. The alternative is to keep support for `FnOnce` dynamic tests in libtest, which is highly non-trivial due to having to plumb multiple layers of `Cow`-like handling through everything. I don't think it's worth it, given that dynamic tests are only used by "standalone" rustdoc and by the tests testing libtest. Overall this saves more than 1s when running coretests (which has 2787 tests) with a hot incremental cache with `--exact char::test_is_numeric`. Before: 7.606s After: 6.484s Given that most of that time is actually spent in rustc, not in the interpreter, that is a very big speedup for the interpreter part.
…d-fields, r=estebank Fix suggestions for names captured by formatting macros Fixes rust-lang/rust#105520 also improve rust-lang/rust#141136. but still can not handle rust-lang/rust#96999. r? @ghost
Currently a `NodeId` is stored in a pair with each nested use tree. This commit changes the pair to a named type `UseTreeAndId`. In most places this doesn't make much difference but in the AST visitor it gets rid of several weird special cases.
Session creation is currently awkward: we build a mostly-initialized session, then use it to initialize a codegen backend, and then use the codegen backend to finish initializing the session. And it's not just awkward: within the Cranelift backend's `init` method `sess.lto()` is called, which consults `sess.thin_lto_supported`, *before* that field has been properly set! In practice it had no effect but it's worth fixing. This commit cleans up this mess. It introduces `EarlySession`, which contains just four `Session` fields, the ones that are needed for codegen backend initialization. It is now a field within `Session`, and `Session` derefs to `EarlySession` to avoid changing a zillion `sess.target`/`sess.opts`/etc. occurrences. `EarlySession` is passed to `init`, which returns a `CodegenBackendInit` that contains the backend-specific information needed to build a `Session`. (It replaces the `replaced_intrinsics`, `fallback_intrinsics`, and `thin_lto_supported` methods.) The `Session` can then be built in a single step. No more `Session`/`CodegenBackend` initialization intermingling. A few functions that previously took a `Session` now take something else, e.g. a `Target`. Some `Session` methods are now `EarlySession` methods. And a new `early_lto` method is used for Cranelift's LTO check.
…enkov Simplify `ast::UseTreeKind` We can make things simpler by adjusting how the ids are stored. Details in individual commits. r? @petrochenkov
Rollup of 10 pull requests Successful merges: - rust-lang/rust#156216 (implement const Iterator for Range) - rust-lang/rust#160697 (rustc: Tweak the effect of `--jobs` on frontend parallelism) - rust-lang/rust#162748 (Enable LLVM Thin LTO for LoongArch64) - rust-lang/rust#162769 (Yeet the `DeepRegionResolver` (earlier called `OpportunisticRegionResolver`)) - rust-lang/rust#162794 (Simplify `ast::UseTreeKind`) - rust-lang/rust#162800 (Cleanups related to RefDecodable) - rust-lang/rust#162826 (wasm: fix ABI for enums with integer layout and ZST fields) - rust-lang/rust#159359 ([rustc_public] Enhance PassMode API) - rust-lang/rust#162196 (Offload cmake cleanups) - rust-lang/rust#162818 (Add regression test for malformed RPITIT bound ICE with the new solver)
flip1995
marked this pull request as ready for review
September 17, 2026 12:06
rustbot
added
the
S-waiting-on-review
|
Lintcheck changes for d43a5a5
This comment will be updated if you push new changes |
rustbot
removed
the
S-waiting-on-review
This was referenced Sep 17, 2026
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
14 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.
r? @ghost
changelog: none