Repository navigation
Rustc pull update - #2264
Open
workflows-stdarch[bot] wants to merge 43 commits into
Open
Rustc pull update#2264workflows-stdarch[bot] wants to merge 43 commits into
workflows-stdarch[bot] wants to merge 43 commits into
Conversation
Pull recent changes from https://github.com/rust-lang/rust via Josh. Previous upstream ref: rust-lang/rust@6bb1652 New upstream ref: rust-lang/rust@2822155 Filtered ref: rust-lang/rustfmt@f77686b Upstream diff: rust-lang/rust@6bb1652...2822155 This merge was created using https://github.com/rust-lang/josh-sync.
Josh subtree pull nightly-2026-10-05
Add regression test for issue 6300
Pull recent changes from https://github.com/rust-lang/rust via Josh. Previous upstream ref: rust-lang/rust@2822155 New upstream ref: rust-lang/rust@1a2c479 Filtered ref: rust-lang/rustfmt@828265c Upstream diff: rust-lang/rust@2822155...1a2c479 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update 2026-10-21
Integration test updates
Allow `llm-assisted` label to be set by users without write access
Pull recent changes from https://github.com/rust-lang/rust via Josh. Previous upstream ref: rust-lang/rust@5d89371 New upstream ref: rust-lang/rust@8592206 Filtered ref: rust-lang/compiler-builtins@68d4f4a Upstream diff: rust-lang/rust@5d89371...8592206 This merge was created using https://github.com/rust-lang/josh-sync.
compiler-builtins subtree update Subtree update of `compiler-builtins` to rust-lang/compiler-builtins@da91091. Created using https://github.com/rust-lang/josh-sync. r? @ghost
They have the same signature now, so we can unify them. The implementation for tuple is selected based on whether the concatenated string contains field names.
…rtdev stdarch subtree update Subtree update of `stdarch` to d01cfec. Created using https://github.com/rust-lang/josh-sync. r? @ghost
Temporarily drop macos-26 jobs Because the `test-aarch64-apple-macos-26-2` job fails often because of disk space issues. See [#t-infra > test-aarch64-apple-macos-26-2 just stops without an error?](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/test-aarch64-apple-macos-26-2.20just.20stops.20without.20an.20error.3F/with/635961872) We still have coverage of macos via the macos-15 jobs. rust-lang/infra-team#307 was created to solve this issue, but I'm not sure how long this will take to be picked up, and this problem is causing some backlog in the bors queue Tracking issue rust-lang/rust#157687 r? jieyouxu
Submodule update of rustc-perf So we can play with rust-lang/rustc-perf#2624 r? @Kobzol
Make `IoSlice` and `IoSliceMut` methods unstably const This enables constructing `IoSlice` and `IoSliceMut` in const contexts without users needing to break the platform abstraction by doing the cast themselves. This is useful for statics. Since all current and plausible future platforms use simple slice-like structs, this should not impose a burden when adding a new platform with a different struct.
…olkertdev More stdarch regression tests This adds regression tests for - rust-lang/rust#159831 - rust-lang/rust#159801 - rust-lang/rust#159474 - rust-lang/rust#124216 Cc @folkertdev try-job: test-x86_64-gnu-llvm*
std: Test the exit behavior of `abort` and `abort_immediate` There has been discussion about possibly bringing `abort` into `core` with `abort_immediate` as a fallback. If this or other changes happen, we would want to make sure `abort` still raises SIGABRT. Since we don't seem to be asserting the exact exit behavior anywhere, add a test here.
Unstably introduce MVP edition migration lint `unmarked_unchecked_type_aliases` together with bikeshed attribute `#[rustc_unchecked_type_alias]` Quoting from https://rustc-dev-guide.rust-lang.org/guides/editions.html#migration-lints: > *Migration lints* are used to migrate projects from one edition to the next. They are implemented with a `MachineApplicable` suggestion which will rewrite code so that it will **successfully compile in both the previous and the next edition**. However, as it stands we can't just stabilize feature `checked_type_aliases` in the next edition because it would break the world (in the next edition); generally speaking, arbitrary implicitly unchecked type aliases (i.e., what we have today on stable) can't just become checked type aliases without breakage. E.g., * the RHS could be ill-formed (most likely diverging const exprs, dyn-incompatible trait refs or unmet projection bounds) in which case the alias could obviously never be migrated as is (this is not a theoretical point; see crater run in rust-lang/rust#161358 for example). * rather unlikely but the user could be ignoring lint `type_alias_bounds` and be writing explicit bounds which would now be enforced at usage sites which could lead to local or downstream breakages (i.e., a major change wrt. SemVer) * more likely, implicit `Sized` bounds would now be enforced at usage sites which could lead to local or downstream breakages * the type alias could be private & used in a public item signature which would now trigger lint `private_interfaces` which might be set to `deny` or stricter leading to (soft) breakage Therefore, there *must* be a mechanism to define unchecked type aliases in the next edition / under feature `checked_type_aliases`. This mechanism could then be used by the edition migration lint for (unchecked) type aliases that cannot be turned into a checked one without breaking the local crate or downstream consumers thereof. Of course, the lint should try to avoid that mechanism where possible. This PR introduces attribute `#[rustc_unchecked_type_alias]` (placeholder name) gated behind new unstable feature `marked_unchecked_type_aliases` to be the aforementioned mechanism. Moreover, it introduces allow-by-default edition migration lint `unmarked_unchecked_type_aliases` gated behind the same feature. The target edition in question is our dummy `future` which was added specifically for cases like this. Note that this PR only contains the *MVP* of the migration lint: Its impl won't try to figure out if adding `#[rustc_unchecked_type_alias]` would actually be necessary since that's most likely relatively involved & can be done iteratively. Part of rust-lang/rust#112792. <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
Remove `TypeKind` from `rustc_codegen_ssa` `TypeKind` is a very LLVM-shaped enum (e.g. there is a single `TypeKind::Integer` but multiple variants for floats because that's what LLVM does) - other backends (e.g. `rustc_codegen_gcc`) usually don't have a single call to get the required information and have to check for each variant individually, even though most callers only care if a type is one or at most a few variants. This PR removes `TypeKind` and `cx.type_kind()` from `rustc_codegen_ssa`, replacing them with `Option`-returning methods `int_width`, `float_type` and `vector_element_type_and_length`. cc @antoyo for `rustc_codegen_gcc` r? @bjorn3
perf: avoid allocating HashSet in is_distinct check on small SwitchInts
Gate `z` inline asm template modifier This PR fixes an unexpected side-effect of rust-lang/rust#158312, as shown in rust-lang/rust#165055: the `z` template modifier is accepted on nightly and beta without needing the `asm_experimental_reg` gate enabled, and this would unexpectedly become stable in the next release. This PR fixes that, with some diagnostics pointing at the feature gate instead of just rejecting the template modifier (the latter can be seen in the second commit). Fixes (after beta backport) rust-lang/rust#165055.
…_file, r=ChayimFriedman2 Fix flaky CI test `named_temp_file_new_creates_file` This fix was suggested here: [#t-compiler/rust-analyzer > miri failing test @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/miri.20failing.20test/near/635432567) r? @ChayimFriedman2
Check associated const binding types For situations such as fn() that cannot be used as type system constant types, normal E0741 is generated in advance and the error type is returned to avoid continuing to enter constant evaluation and trigger ICE. Fix: rust-lang/rust#161100
…xyUwU,bit-aloo give next-solver's `evaluate_const` its own `try_evaluate_const` logic Currently evaluating type-level constants is convoluted as code is split in a lot of scattered functions across compiler which makes it hard to reason about. This PR refactors next-solver's CTFE entry point, only commit changing behavior is rust-lang/rust@8c2dc29, by replacing `evaluate_const` call to normalization goal which also regressed some diagnostics. for context see [#project-const-generics > evaluate_const is scary](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/.60evaluate_const.60.20is.20scary) r? BoxyUwU
make powerpc `Complex` ABI GCC-compatible tracking issue: rust-lang/rust#154023 The first commit gets the coercions right, but breaks down once the available registers are close to exhausted. GCC never splits a complex value across registers and the stack: when a complex value only partially fits, the remaining GPRs are consumed and the whole complex value (and any subsequent arguments) are passed via the stack. This means we need an accurate accounting of the number of GPRs that have been consumed so far, so that we can emit padding to consume the remaining GPRs when a value needs to be passed on the stack. I've tried my best at that in commit 2, testing equivalence empirically with GCC. Rather than getting the GCC algorithm right, instead we make a second pass over the arguments, and deduce the number of GPRs from the `PassMode` that the first pass determined for each argument. That seems to do the trick.
Avoid ICE on None from prepare_vtable_segments Closes rust-lang/rust#153368 I actually just realized None caused the ICE and None was semantic for the caller, meaning I could just propagate the None instead of unwrapping and to my surprised ICE is fixed and no test is broken! The issue here is that I'm not sure the implications of changing this signature, but it seems to work fine. r? trait-system-refactor-initiative
…alfJung follow up for global-alloc-reentry test Follow up pr to rust-lang/rust#163730, fixing post-merge review comments - changed `swap` to `store` instead for the flags - hopefully made the comments less confusing about what the pthread section does
Bless mir-opt panic-abort tests We really need to be testing this in CI…
skip max_repr_align in Layout::eq_abi We don't have to compare all fields of `Layout`. Some of them are irrelevant most of the time, only some special callconv adjustments use them. Given that we compare both `PassMode` and `Layout`, we will notice those differences in `PassMode` comparison. Comparing them also in `Layout` is too strict as the values can differ without actually resulting in a different ABI. For instance, `max_repr_align: Some(1)` is effectively the same as `max_repr_align: None`. Fixes rust-lang/miri#5500 r? @oli-obk
Syntactically allow C-variadics in parenthesized argument lists Can be reviewed commit by commit, every commit passes tests. r? @fmease Fixes rust-lang/rust#160797 Part of rust-lang/rust#158499
…anBrouwer move `#[rustc_allow_const_fn_unstable]` attr check to attr parsing stage Part of [#153101](rust-lang/rust#153101). r?@JonathanBrouwer
Remove stability note from `rust_splat` I did not find the note to be particularly useful...
…uwer Rollup of 22 pull requests Successful merges: - rust-lang/rust#165032 (stdarch subtree update) - rust-lang/rust#165123 (Temporarily drop macos-26 jobs) - rust-lang/rust#165072 (Submodule update of rustc-perf) - rust-lang/rust#144090 (Make `IoSlice` and `IoSliceMut` methods unstably const) - rust-lang/rust#162342 (More stdarch regression tests) - rust-lang/rust#163909 (std: Test the exit behavior of `abort` and `abort_immediate`) - rust-lang/rust#164766 (Unstably introduce MVP edition migration lint `unmarked_unchecked_type_aliases` together with bikeshed attribute `#[rustc_unchecked_type_alias]`) - rust-lang/rust#164916 (CI: rfl: move job forward to Linux v7.3) - rust-lang/rust#164924 (Remove `TypeKind` from `rustc_codegen_ssa`) - rust-lang/rust#164969 (perf: avoid allocating HashSet in is_distinct check on small SwitchInts) - rust-lang/rust#165083 (Gate `z` inline asm template modifier) - rust-lang/rust#165087 (Fix flaky CI test `named_temp_file_new_creates_file`) - rust-lang/rust#161131 (Check associated const binding types) - rust-lang/rust#161418 (give next-solver's `evaluate_const` its own `try_evaluate_const` logic) - rust-lang/rust#164315 (make powerpc `Complex` ABI GCC-compatible) - rust-lang/rust#164476 (Avoid ICE on None from prepare_vtable_segments) - rust-lang/rust#165003 (follow up for global-alloc-reentry test) - rust-lang/rust#165020 (Bless mir-opt panic-abort tests) - rust-lang/rust#165066 (skip max_repr_align in Layout::eq_abi) - rust-lang/rust#165080 (Syntactically allow C-variadics in parenthesized argument lists) - rust-lang/rust#165081 (move `#[rustc_allow_const_fn_unstable]` attr check to attr parsing stage) - rust-lang/rust#165082 (Remove stability note from `rust_splat`)
Update LLVM submodule Should fix the following issues: rust-lang/rust#163626 rust-lang/rust#163734 rust-lang/rust#164297 rust-lang/rust#164469 rust-lang/rust#164584 rust-lang/rust#164825
Don't ignore unknown LLVM diagnostics Rust currently ignores LLVM diagnostic kinds that it does not know about. This means that we sometimes ignore error diagnostics, which can then result in silent miscompiles. This exposes `LLVMGetDiagInfoSeverity` returning `DiagnosticSeverity`, renamed from `DiagnosticLevel` to match LLVM terminology. Custom code to fetch the diagnostic severity for inline asm diagnostics can then be dropped. For unknown diagnostics, we emit a warning/error depending on severity. Notes and remarks continue to be ignored. One oddity I ran into along the way is that the linker diagnostic has severity error, but we only report a warning. I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from). Fixes rust-lang/rust#146393.
…cote More derive(Debug) cleanups for structs This removes duplication from the debug helpers and unifies tuples with structs. More details in individual commits. I think this is makes the code simpler, but it's a bit of a judgement call. r? nnethercote
New solver opts for diesel (part 3) A sequel to rust-lang/rust#163981 and rust-lang/rust#164234. These ones mostly relate to allocations. Details in individual commits. Local measurements: ``` solver icounts (B) ------ ----------- old 36.4 new (orig) 44.5 (1.22x) new (this PR) 42.4 (1.16x) ``` Also some small improvements on a range of other benchmarks. r? @jdonszelmann
…uwer Rollup of 2 pull requests Successful merges: - rust-lang/rust#165140 (More derive(Debug) cleanups for structs) - rust-lang/rust#165160 (New solver opts for diesel (part 3))
Pull recent changes from https://github.com/rust-lang/rust via Josh. Previous upstream ref: rust-lang/rust@1a2c479 New upstream ref: rust-lang/rust@3e92e1a Filtered ref: rust-lang/rustfmt@4bc2eb3 Upstream diff: rust-lang/rust@1a2c479...3e92e1a This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update 2026-11-02
rustfmt subtree update (v1.12.0) Subtree update of `rustfmt` to rust-lang/rustfmt@4408c4c. Closes rust-lang/rustfmt#7225. Created using https://github.com/rust-lang/josh-sync. [See the CHANGELOG for all notable changes going out as part of `v1.12.0`](https://github.com/rust-lang/rustfmt/blob/main/CHANGELOG.md#1120-2026-12-24) r? @jieyouxu
This updates the rust-version file to 2d20b42b883dcfc014f3c2c56081eeb6091c2179.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Previous upstream ref: rust-lang/rust@16d1ffa New upstream ref: rust-lang/rust@2d20b42 Filtered ref: 47ce4bb Upstream diff: rust-lang/rust@16d1ffa...2d20b42 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the pull request, and welcome! The Rust Project has assigned @Amanieu (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks. Why was this reviewer chosen?The reviewer was selected based on:
|
This branch has not been deployed
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
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.