Rustc sync 2026 09 13 - #2207
Merged
Merged
Conversation
…rtdev stdarch subtree update Subtree update of `stdarch` to rust-lang@50afa9f. Created using https://github.com/rust-lang/josh-sync. r? @ghost
Simplify the unwind crate Use cfg_select! and unify type definitions.
…llot Stop using prefix_tys *This is a member of a patch series to replace rust-lang/rust#135527.* This function hints at an early commitment to coroutine memory layout. We should not give promises on how upvars are allocated.
…-Simulacrum triagebot: cc miri on any special-casing of miri in the standard library --- Blocked until rust-lang/triagebot#2462 is merged and deployed.
Apply `#[diagnostic::opaque]` to macros expanding to built-in syntax For context, thin wrapper macros expanding to built-in syntax `builtin # SYNTAX(…)` (internal feature `builtin_syntax`) is an alternative to built-in macros (`#[rustc_builtin_macro]`) for introducing new syntax constructs that takes slightly less code to implement in the compiler (since one doesn't need to write boiler-plate expanders, see RUST-122806 for example). However, one disadvantage of that approach is the fact that the thin wrapper macro is a normal macro and is thus considered "interesting" wrt. macro backtraces. The fact that it expands to `builtin # SYNTAX(…)` should be considered an implementation detail and thus these macros should be considered opaque. I've applied `#[diagnostic::opaque]` (rust-lang/rust#158608) to all of these macros which successfully suppresses diagnostic notes of the form `` this error originates in the macro `SYNTAX` (…) ``. Well, it doesn't actually omit the expansion from the macro backtrace when `-Zmacro-backtrace` is passed which was surprising but seems intentional looking at the linked PR. Still, this is better than nothing. r? @mejrs
…nthey implement `const_binary_search` tracking issue: rust-lang/rust#159532 This makes unstably `const` the following public api: `core::slice::binary_search` `core::slice::binary_search_by` `core::slice::binary_search_by_key` `core::slice::partition_point` Happy to make a tracking issue if these are acceptable.
…uwer Rollup of 6 pull requests Successful merges: - rust-lang/rust#159517 (stdarch subtree update) - rust-lang/rust#159010 (Simplify the unwind crate) - rust-lang/rust#156650 (Stop using prefix_tys) - rust-lang/rust#159152 (triagebot: cc miri on any special-casing of miri in the standard library) - rust-lang/rust#159522 (Apply `#[diagnostic::opaque]` to macros expanding to built-in syntax) - rust-lang/rust#159528 (implement `const_binary_search`)
perf: dep_graph: deduplicate task reads with an epoch-filtered index recorder Follow up of rust-lang/rust#158794 During this PR we compared three variants to replace the hashset for tracking the seen set of reads: 1. epoch filter with u32 slots: instruction count -1.7%, but max-RSS +2.6% 1. bitset: instruction count -0.6%. I was able to make a faster version of this by avoiding the resize checks in `GrowableBitSet`, but it was always slower than the epoch filter because the seen items need to be cleared after use. 1. epoch filter with u8 slots: instruction count -1.6%, max-RSS neutral. This seems to have the best trade-off and is now the current change.
…=lcnr Get rid of `StructurallyRelateAliases` Part of rust-lang/rust#155345 Finally we can get rid of the last use of `StructurallyRelateAliases::Yes`. r? lcnr
Replace weak only lang items with a custom attribute When I added the `invalid_runtime_symbol_definitions` and `suspicious_runtime_symbol_definitions` lints in rust-lang/rust#155521 I added the concept of "weak only" lang item. It's a `LangItem` that has no implementation, this is useful because the `core` symbols where not directly called, they were inserted by the compiler. This mechanism work well, but T-lang [approved](rust-lang/rust#158522 (comment)) the extension to "all extern functions referenced by the standard library", which makes the lang item approach impractical as we needs to update 5 files just to declare them. I'm not sure we can ask library contributor to do the dance for each `extern "C"` functions. But the most problematic thing is that many extern functions in `std` come from `libc` not `std`, and adding lang items there is just no feasible I think. Instead this PR proposed that we introduce a proper mechanism for them by adding a attribute `#[rustc_canonical_symbol = "..."]`, which is encoded and decoded in `rmeta` like lang items and diagnostics items. This simplifies the declaration as we only need to put the attribute to be effective `#[rustc_canonical_symbol = "open"]`. It also opens up many possibilities (none implemented here) like putting them on `use` statements (so we don't need to modify `libc`) or having the attribute be placed on a module. The table may also be useful on it's own if we want someday to do it for all crates, not just the standard library. Follow up to rust-lang/rust#155521 and rust-lang/rust#158522
…henkov Resolve: more preperation work for parallelizing the import resolution loop This is basically rust-lang/rust#158845 but we do not: - actually use `par_slice` because: - we do not migrate `CmRefCell` to use `RwLocks` (yet) because of perf reasons. The resolution loop is now in place instead of recollecting indeterminate imports. r? @petrochenkov
Apply RemoveNoopLandingPads post-monomorphization On Cargo this cuts ~5% of the LLVM IR lines we generate (measured with -Cno-prepopulate-passes). Closes rust-lang/rust#159399.
…leywiser,scottmcm Closures inherit #[optimize] from the enclosing function by default. Tracking issue: rust-lang/rust#54882 Stabilization PR: rust-lang/rust#157273
…twco Fix `bool` calling convention for aarch64, etc. We have been making a broad assumption about the way `bool` should be handled that *may* be correct for Rust calling Rust but is wildly incorrect for cross-language FFI calls. The ABI of `bool` is generally poorly-specified in any C psABI, and often deliberately allows for deviation after the first 8 bits. This has surfaced as a bug that can corrupt Rust programs on aarch64, but it is a potential latent bug when it comes to every ABI. The simplest solution is to simply stop applying the special case when generating `bool`'s ArgAttributes. This yields control to the later ABI implementations, which may then sign or zero extend the `bool` (or not) according to their needs.
bootstrap: update cc-rs to `1.2.62` * Removes deprecated `static_flag` build methods
Type fallback refactorings - Don't merge different kinds of infer variables into `Ty` before matching them back - Do fallback only on root vars (this is semantically equivalent to what we currently do; unifying any of the infer vars from the same equivalence class necesserily affects all of them) (this makes rust-lang/rust#159003 a bit less hacky though) - Do some simplification that has been allowed by the previous changes cc @lcnr
[rustdoc] Do not take `doc(cfg())` into account when filtering doctests Part of rust-lang/rust#147033. Because it was using the `extract_cfg_from_attrs` common function, it was taking into account the `doc(cfg())` attributes the same as if they were a `cfg`. I didn't mark this PR as "fix" because I didn't handle the case of the doctest not being marked as ignored because I'm not sure if we should revisit the fact that we ignore these doctests or if we should just mark them as ignored (because of `target_feature(enable = "...")`). Setting @fmease as reviewer as they are likely the only one with context about this issue. 😆 r? @fmease
rustc_llvm: Emit module summaries when using -Clto=fat Currently, module summaries are only emitted with thin lto. If we would link full/fat lto'd rust code against lto'd c++ code built with CFI (or WPD), those passes would fail during the link step because the participating rust modules are missing module summaries. Rust code does not know at compile-time if it would be participating in some special link which may require module summaries, so this PR ensures module summaries are unconditionally emitted for full/fat lto, just like with thin lto. The WriteBitcodeToFile function just invokes the normal BitcodeWriterPass under the hood, but doesn't provide a way to set the argument for emitting module summaries. So this patch just adds the pass directly and sets that argument. This is a rebase of @PiJoules's rust-lang/rust#158099, which also should fix up the tests with the gcc tools.
Update rustc-perf submodule To bring in rust-lang/rustc-perf#2520, which should unblock rust-lang/rust#160527.
…oli-obk treat no_mangle_generic_items as hard error instead of lint warning Reference PR: - rust-lang/reference#1904 In rust-lang/miri#4929 (comment), rustc should reject the no_mangled generic function. This PR treat is as a hard error
Fix, simplify, and document doc meta finalize mode Follow up rust-lang/rust#159415 (comment) Get rid of the mode where you can finalize the CCI and generate more docs at the same time. It isn't used in Cargo, and probably won't be used elsewhere? Fixes a bug where the crate index, settings page, and help page aren’t generated at finalize time. Update documentation. Move CCI tests to run-make, so that we can test the finalize step’s CLI.
Add CoerceShared field-wise reborrow WF checks This PR attempts to add a well-formedness check for CoerceShared. Split out of rust-lang/rust#157101 r? @aapoalas
Add Enzyme bugfix to support rust+llvm23
…nia-e Reorder the methods in `#[rustc_must_implement_one_of]` So that their order will be the preferred order for implementations (assuming implementing `read_buf()` is better), like @joshtriplett said in rust-lang/rust#106643 (comment). r? libs
… r=lqd Revert "codegen_ssa: no dbginfo for scalable vec local w/ `-O0`" This partially reverts commit ebe72104f00ca57e02f7ac70d78089727d5462b5 (it keeps the tests), from rust-lang/rust#158088. The workaround in that patch is no longer necessary with the upgrade to LLVM 23 in rust-lang/rust#158734. I've confirmed that the stdarch tests also continue passing with this patch applied. r? @lqd
…useZ4 Re-enable bool indexing assembly test for LLVM 23 fixes rust-lang/rust#160521 Follow-up rust-lang/rust#159977
… r=mejrs Remove `OnDuplicate::Custom` It was only used for one attribute, where it was not particularly helpful
…au,fmease [rustdoc] Create output file after we checked that the standalone markdown file is valid This PR makes the creation of the output (HTML) file after we checked that the input markdown is valid to prevent the output file content to be truncated ([`File::create` doc](https://doc.rust-lang.org/nightly/std/fs/struct.File.html#method.create)) in any case. r? @Urgau
…uwer Rollup of 12 pull requests Successful merges: - rust-lang/rust#159014 ([rustdoc] Do not take `doc(cfg())` into account when filtering doctests) - rust-lang/rust#159029 (rustc_llvm: Emit module summaries when using -Clto=fat) - rust-lang/rust#160574 (Update rustc-perf submodule) - rust-lang/rust#154585 (treat no_mangle_generic_items as hard error instead of lint warning) - rust-lang/rust#159473 (Fix, simplify, and document doc meta finalize mode) - rust-lang/rust#157489 (Add CoerceShared field-wise reborrow WF checks) - rust-lang/rust#160532 (Add Enzyme bugfix to support rust+llvm23) - rust-lang/rust#160545 (Reorder the methods in `#[rustc_must_implement_one_of]`) - rust-lang/rust#160558 (Revert "codegen_ssa: no dbginfo for scalable vec local w/ `-O0`") - rust-lang/rust#160566 (Re-enable bool indexing assembly test for LLVM 23) - rust-lang/rust#160569 (Remove `OnDuplicate::Custom`) - rust-lang/rust#160576 ([rustdoc] Create output file after we checked that the standalone markdown file is valid)
…enkov perf: Lock-free root fast paths for hygiene queries `normalize_to_macros_2_0`, `normalize_to_macro_rules` and `outer_expn_is_descendant_of` take the `HygieneData` lock even for the root syntax context, the common case, where the answer is fixed: the root normalizes to itself, and everything descends from the root expansion. This PR avoids the lock, like the existing fast paths in `ExpnId::is_descendant_of`.
Reachable cleanups A few small dataflow analysis cleanups related to reachability. Details in individual commits. r? @cjgillot
Update cargo submodule 21 commits in 7c83d4cc0953b81d823e47d640c64da9b8bd4fac..c79e8f89441b3e73d6d65d125c0c745792808c74 2026-07-29 21:34:53 +0000 to 2026-08-04 19:17:33 +0000 - fix(diag): Ensure diagnostic titles work without snippets (rust-lang/cargo#17304) - refactor: Remove unnecessary mut in sources (rust-lang/cargo#17305) - feat(trim-paths): emit unremap files for final artifacts (rust-lang/cargo#17303) - fix: prevent panic when `package.build` is empty (rust-lang/cargo#17268) - Add a suggestion when adding `[lints]` to a workspace to use `[workspace.lints]` instead (rust-lang/cargo#17300) - chore(deps): update embarkstudios/cargo-deny-action action to v2.1.1 (rust-lang/cargo#17291) - refactor: move sysroot lookup to GlobalContext (rust-lang/cargo#17276) - fix(trim-paths): unambiguous and reversible remap rules (rust-lang/cargo#17302) - Avoid parsing unchanged lockfiles (rust-lang/cargo#17301) - Remove unnecessary to_path_buf (rust-lang/cargo#17295) - chore(deps): update cargo-semver-checks to v0.50.0 (rust-lang/cargo#17297) - chore(deps): update actions/checkout action to v6.1.0 (rust-lang/cargo#17290) - Remove unnecessary return at end of functions (rust-lang/cargo#17292) - make __CARGO_TEST_FORCE_ARGFILE available in distributed builds (rust-lang/cargo#17293) - Fix manual_readme lint for lower-priority README files (rust-lang/cargo#17208) - fix(git): make checkout names independent of git config (rust-lang/cargo#17289) - fix(diag): Rename redundant_readme to manual_readme (rust-lang/cargo#17288) - Remove redundant double call .to_string() (rust-lang/cargo#17286) - fix(completions): complete paths for cargo run arguments (rust-lang/cargo#17284) - test(git): exercise multi git revision lockfile (rust-lang/cargo#17279) - add context to lints documentation (rust-lang/cargo#17273) r? ghost
…t_solver, r=lcnr,bit-aloo session: Enable next-solver globally for assumptions-on-binders Zulip: https://rust-lang.zulipchat.com/#narrow/channel/618216-t-types.2Fcall-for-participation/topic/assumptions.20on.20binders.3A.20enable.20next-solver.20automatically/with/614548133 `-Zassumptions-on-binders` already needs the next trait solver, but you still had to pass `-Znext-solver` by hand. Easy to forget, and some spots (feature gates) read `next_solver.globally` directly, so just special-casing `next_trait_solver_globally()` wouldn't cut it. After `-Z` parsing, if assumptions-on-binders is on, force `NextSolverConfig { coherence: true, globally: true }`. Same pattern as `-Zretpoline-external-thunk`. Flag order doesn't matter. `-Znext-solver=no` gets overridden too; imo that's the right call since the assumptions code can't run on the old solver. A hard conflict error would also be fine, just more annoying for day-to-day hacking. Covered the flag alone, both orderings, and `=no` in a unit test. Dropped the explicit `-Znext-solver` from one UI test under `assumptions_on_binders`. btw idk if we should strip `-Znext-solver` from the rest of that folder asap or leave the redundancy. irl I'd leave it for now. fyi this also means anything checking `next_solver.globally` sees the effective config. ltm if you'd rather go the conflict-error route instead of overriding `=no`.
[perf] Reuse existing trait reference instead of recreating it. Effectively, do one step of common subexpression elimination, manually. We can reuse the existing interned reference made a few lines prior, without needing to recreate it. r? @lcnr **AI disclosure:** The optimization opportunity here was discovered as part of a systematic probe for missed optimizations using a combination of both traditional and AI tools. The code here was initially prototyped and vetted by AI tools, followed by additional manual work. I stand behind the quality of the code I'm submitting, and I vouch it's as good or better than if no AI tools were in the loop.
…gen_regions, r=BoxyUwU,lcnr trait_solver: normalize next-gen region constraints fixes rust-lang/rust#157729 -zassumptions-on-binders can produce next-gen region constraints that mean the same thing but don't have the same shape. in this case object candidate merging stayed ambiguous and instance resolution later hit the ice. imo normalizing the constraint at the response boundary is the least weird place for this, because candidate selection shouldn't need to know which vtable looks nicer. canonicalize and evaluate the next-gen region constraint before response canonicalization, then cover the dyn derived<p> supertrait case from the issue. lgtm locally with the focused test, tests/ui/traits/next-solver, and tests/ui/assumptions_on_binders. idk if there's a better home for the helper call, but ltm this keeps the fix pretty narrow.
mir: prohibit projection into scalable vec Fixes rust-lang/rust#160580. Preventing projections into scalable vectors is an oversight from the initial implementation and something we should fix. I'm surprised it caused a stdarch CI failure as reported by rust-lang/rust#160580, as nothing in rustc or stdarch seems to have changed that would have caused that to start happening as far as I can tell. This likely won't fix that stdarch CI failure if it keeps happening, because if there is a projection coming from somewhere then that needs to be fixed - nevertheless, preventing them as in this patch is the right thing to do. I've tested this against the stdarch CI locally.
…ffleLapkin MaybeDangling: ensure references fit inside the address space In the RFC we left open the question of the exact validity invariant for references inside `MaybeDangling`. This PR implements the strictest invariant I can think of: we already require references to be aligned, now we also require "addr + size" to be computable without overflow. This ensures that whatever niches we add to references in the future, `MaybeDangling` preserves those niches. Cc @rust-lang/opsem @WaffleLapkin Tracking issue: rust-lang/rust#118166 r? @oli-obk
Use recognizer functions for enums and tuple structs Non-urgent, but related to rust-lang/rust#160331 We currently shove most user defined types through `synthetic_lookup` as I hadn't gotten around to using type recognizers yet. If we want tests to skip outputting types when the type doesn't have a visualizer, we should also not attach a (useless) visualizer to most UDTs. The only things `synthetic_lookup` catches that aren't already caught by the regexes are tuple-structs and sum-type enums. This patch adds targeted type recognizers for those, and no longer sends types through `synthetic_lookup` at all on LLDB 19+ this doesn't affect `pretty-std.rs` since all those types have visualizers, but it will affect other tests if/when they're converted (e.g. `tests/debuginfo/struct-in-struct.rs`) r? @Kobzol, @jieyouxu
…r=mejrs Fix inaccurate description for crate and pathroot Same as https://github.com/bb1yd/rust/blob/8ab9fdff5a91b9f2b5ed57fb0275452d9a0d0280/compiler/rustc_resolve/src/diagnostics/impls.rs#L3027-L3035
Docs & bors: Replace mentions of libs-api with libs Per [the libs refactor RFC](rust-lang/rfcs#3984), libs-api will not exist anymore soon & so replace mentions of it with libs.
…r=joboet Fix references to unsupported on sys::paths::unix Compilation was seemingly broken by PR rust-lang/rust#150885, commit f2dd93228abcf29ab85960457df7a6f828eb3cb9, by removing one of the nested `mod`s. I'm one of the `armv7-sony-vita-newlibeabihf` target maintainers. Summary of changes for affected targets: - `armv7-sony-vita-newlibeabihf`: now compiles - `armv6k-nintendo-3ds`: still doesn't compile, apparently due to an issue introduced in rust-lang/rust#158168, which should be fixed by rust-lang/rust#160170 - all espidf targets: I haven't compiled any of them as I don't have the toolchain installed, but it should be on the same as 3DS. The same errors can be seen in [does-it-build](https://does-it-build.noratrieb.dev/build?nightly=2026-08-09&target=xtensa-esp32s3-espidf&mode=std)
Use `remove_dir_all` for `./x clean` This should work better in most cases (and be faster) particularly on Windows. I've left the old implementation more or less intact to provide diagnostics on failure. But it could be removed if desired.
…uwer Rollup of 9 pull requests Successful merges: - rust-lang/rust#158404 (trait_solver: normalize next-gen region constraints) - rust-lang/rust#160631 (Do not eagerly download rustfmt in bootstrap) - rust-lang/rust#160642 (mir: prohibit projection into scalable vec) - rust-lang/rust#160749 (MaybeDangling: ensure references fit inside the address space) - rust-lang/rust#160791 (Use recognizer functions for enums and tuple structs) - rust-lang/rust#160500 (Fix inaccurate description for crate and pathroot) - rust-lang/rust#160590 (Docs & bors: Replace mentions of libs-api with libs) - rust-lang/rust#160825 (Fix references to unsupported on sys::paths::unix) - rust-lang/rust#160852 (Use `remove_dir_all` for `./x clean`) Failed merges: - rust-lang/rust#160829 (bootstrap: Make `main.rs` a stub that calls into the library crate)
Diagnostics ICE when replaying proof trees with next-solver When diagnostics replay proof tree state, rebuilding a canonical state can fail to match the current inference state. With -Znext-solver=globally, this could panic while reporting an error, avoiding the panic. Make proof tree replay fallible in diagnostics and fall back to the current obligation when replay fails. Add a regression test for the higher-ranked PartialEq and PartialOrd case. Fixes rust-lang/rust#151304.
Optimize new solver unification table ops The current code uses the `ena` crate in sub-optimal ways. Improving this gives big speed wins for the new trait solver on some benchmarks. Details in individual commits. r? @lcnr
…uwer Rollup of 7 pull requests Successful merges: - rust-lang/rust#160629 ([Priroda] Add bootstrap test and check steps) - rust-lang/rust#160811 (Fix `visible_parent_map` fallback map merging perf regression) - rust-lang/rust#154329 (Diagnostics ICE when replaying proof trees with next-solver) - rust-lang/rust#157841 (Ensure inferred let pattern types are well-formed) - rust-lang/rust#159300 (Implement `to_string()` on `ByteStr` and `ByteString`) - rust-lang/rust#160858 (Add regression test for assoc const panic ICE in match) - rust-lang/rust#160864 (Rename `HostEffectPredicate` to `HostEffectClause`)
Switch try jobs to c8a.8xlarge This also expands the instance type list. Our current selection (12xlarge) is at best 2-3 minutes faster than 8xlarge based on rough benchmarks, which isn't worth the extra ~$0.72/build. See description of rust-lang/simpleinfra#1132 for those results. We expand the instance list to include even smaller instances because we might experiment with using those smaller instances for non-try jobs (e.g., auto and unrolled perf builds) because latency matters less there. That's not done in this commit though. Unfortunately I think we cannot easily test this before landing it, since AFAICT bors will read the configuration only once it's actually on main. rust-lang/bors-kindergarten#59 (once merged) should give us some test experience with this before we proceed with things in rust-lang/rust. r? Kobzol
This updates the rust-version file to 1e5ee356374211706221b71b6106d297a646ee57.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 1e5ee356374211706221b71b6106d297a646ee57 Filtered ref: b4f59cc Upstream diff: rust-lang/rust@fcbe791...1e5ee35 This merge was created using https://github.com/rust-lang/josh-sync.
Contributor
Author
|
r? @ghost |
folkertdev
marked this pull request as ready for review
August 13, 2026 11:01
Collaborator
|
r? @sayantn rustbot has assigned @sayantn. Use Why was this reviewer chosen?The reviewer was selected based on:
|
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
7 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.
No description provided.