Rustc pull update - #3003
Merged
Merged
Conversation
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@7fb284d Filtered ref: rust-lang/compiler-builtins@980dacc Upstream diff: rust-lang/rust@68ffae4...7fb284d This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@f73951d Filtered ref: rust-lang/compiler-builtins@30e5485 Upstream diff: rust-lang/rust@7fb284d...f73951d This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@2c39ff4 Filtered ref: rust-lang/rust-analyzer@3b5a9a7 Upstream diff: rust-lang/rust@7fb284d...2c39ff4 This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@2c39ff4 Filtered ref: rust-lang/compiler-builtins@87fd30b Upstream diff: rust-lang/rust@f73951d...2c39ff4 This merge was created using https://github.com/rust-lang/josh-sync. (I also had to resolve a feature gate conflict in `lib.rs`.)
Rustc pull update
internal: Download all artifacts in a single step
internal: Drop `zigbuild` support
fix: emit E0600 when unary `!`/`-` is applied to unsupported type
minor: skip iter excludes 'into_iter' method
fix: allow `asm!` label blocks to diverge
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@f7d782a Filtered ref: rust-lang/rust-analyzer@0417161 Upstream diff: rust-lang/rust@2c39ff4...f7d782a This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@f7d782a Filtered ref: rust-lang/compiler-builtins@1ebbb4d Upstream diff: rust-lang/rust@2c39ff4...f7d782a This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
minor: Fix 1.98.0 Clippy and rustfmt
perf: Optimize the heck out of the storage of token trees
…k-overflow fix:prevent stack overflow for recursive ADT layouts
fix: Fix unsafeck of `&raw *`
fix: Fix HIR lowering of params of trait assoc fns
fix: Push a generic params scope for consts
allow `-Ldependency` search paths for panic runtimes Part of [build-std=always RFC](https://rust-lang.github.io/rfcs/3874-build-std-always.html). This PR supports `-Ldependency=` search paths for panic runtimes. This will allow Cargo to treat panic runtimes as regular transitive dependencies, rather than special-casing them. To do so: 1. During panic runtime injection we remove the early‑return `only_rlib` check. As a result the panic runtime is injected as a conditional dependency when building `std` and is subsequently included in `std`'s metadata. When building a crate that uses `std`, the panic runtime is resolved through `resolve_crate_deps` in the same way as any other transitive dependency. </br> For a prebuilt `std` (unlike `build-std`), the `-Cpanic=` option passed to `std` may differ from that passed to its dependents, so we might still need to inject another panic runtime as a direct dependency. However, this is not important in the context of prebuilt std. 2. `NoPanicStrategy` is checked only for `panic_abort`. We can compile `panic_unwind` with `-Cpanic=abort` for some targets. This was previously overlooked. #### Summary of the history and discussions in this PR 1. In the first iteration of this PR `PathKind` for injected dependencies was simply changed from `-Lcrate=` to `-Ldependency`, but this raised a [concern](rust-lang/rust#160007 (comment)). Bjorn3 [suggested](rust-lang/rust#160007 (comment)) to include both panic runtimes as a dependency of `std` so we don't have to inject it as a dependency for any user of `std`. The correct one should then be activated later in `dependency_format.rs`. 2. In the second iteration Bjorn3's suggestion was implemented. The problem was that for `build-std=always`, we might want to avoid building `panic_unwind` when not necessary. From the compiler perspective we need to </br> 2.1. Either always resolve `panic_unwind` and ignore any resulting error. (might lead to bugs) 2.2. Or conditionally resolve `panic_unwind`. For `build-std` we might rely on `-Cpanic=` option for this in accordance with [panic strategies](https://rust-lang.github.io/rfcs/3874-build-std-always.html#panic-strategies) but for prebuilt `std` this will fail for some targets. </br> It was decided to relax the implementation so we can inject panic runtime as direct dependency for prebuilt `std`. 3. Third iteration: we are here cc @adamgemmell
Rename it `BUILTIN_ATTRIBUTE_SET` because it's a set, and use `contains` instead of `get` where appropriate.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 45f215f136e00d8a74c69afde2f71be3f16837cf Filtered ref: 2e55b234943f43e4b52bbfba006744b9a4318124 Upstream diff: rust-lang/rust@f7d782a...45f215f This merge was created using https://github.com/rust-lang/josh-sync.
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@f899669. Created using https://github.com/rust-lang/josh-sync. r? @ghost
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang/rust#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang/rust#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
…trochenkov Add test for parallel compiler reproducible build Adds a test for reproducible binaries when using parallel compiler. Confirmed with bisection and manual testing that rust-lang/rust#144722 fixed rust-lang/rust#140413, added test fails before commit (075ce31bd39c68b911edda233f0af3f40113212b) from rust-lang/rust#144722. ```rust ******************************************************************************** Regression in nightly-2025-08-14 ******************************************************************************** fetching https://static.rust-lang.org/dist/2025-08-13/channel-rust-nightly-git-commit-hash.txt nightly manifest 2025-08-13: 40 B / 40 B [============================================================================================================================================================================] 100.00 % 357.18 KB/s converted 2025-08-13 to 8e62bfd311791bfd9dca886abdfbab07ec54d8b4 fetching https://static.rust-lang.org/dist/2025-08-14/channel-rust-nightly-git-commit-hash.txt nightly manifest 2025-08-14: 40 B / 40 B [============================================================================================================================================================================] 100.00 % 123.86 KB/s converted 2025-08-14 to 3672a55b7cfd0a12e7097197b6242872473ffaa7 looking for regression commit between 2025-08-13 and 2025-08-14 fetching (via remote github) commits from max(8e62bfd311791bfd9dca886abdfbab07ec54d8b4, 2025-08-11) to 3672a55b7cfd0a12e7097197b6242872473ffaa7 ending github query because we found starting sha: 8e62bfd311791bfd9dca886abdfbab07ec54d8b4 get_commits_between returning commits, len: 7 commit[0] 2025-08-12: Auto merge of #144678 - jdonszelmann:no-mangle-extern, r=bjorn3 commit[1] 2025-08-12: Auto merge of #145295 - Kobzol:unify-stages, r=jieyouxu commit[2] 2025-08-13: Auto merge of #145093 - nikic:dead-on-return, r=nnethercote commit[3] 2025-08-13: Auto merge of #145334 - Kobzol:rollup-fs5a133, r=Kobzol commit[4] 2025-08-13: Auto merge of #144722 - ywxt:parallel-reproducibile, r=SparrowLii commit[5] 2025-08-13: Auto merge of #145298 - nikic:llvm21-rc3, r=cuviper commit[6] 2025-08-13: Auto merge of #145366 - GuillaumeGomez:rollup-v0a6v3u, r=GuillaumeGomez ``` Fixes rust-lang/rust#140413. r? @petrochenkov
…hanBrouwer `rustc_feature` cleanups Various cleanups. Details in individual commits. r? @JonathanBrouwer
remove `_{style}` recovery for diagnostic structs
Followup to rust-lang/rust#103575
Also documents the `style = "..."` option.
…anBrouwer Move track_caller on closures gating to attribute parsing I noticed this while reviewing rust-lang/rust#161958
std: implement `File::fsync` for Hermit - hermit-abi 0.5.3 exposes `fsync`, so the operation no longer has to return `Unsupported`. cc: @mkroening
Deduplicate `InstrumentFnAttr` cc @pmur Instead of having a `Default` variant (which can't be specified in the attribute, it only does on/off), use an Option to model "no attribute used".
fix typo in feature documentation This is causing failing local executions of `typos-cli` (used in CI) in rust-analyzer. rust-analyzer uses the feature documentation to produce generated code.
…uwer Rollup of 16 pull requests Successful merges: - rust-lang/rust#137720 (support `#[target_feature(enable = ...)]` on `#[naked]` functions) - rust-lang/rust#160534 (stabilize smart pointer map functions) - rust-lang/rust#160551 (mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering) - rust-lang/rust#160989 (Make sin, cos, exp, exp2, log, log2, log10 generic) - rust-lang/rust#161861 (mir_build: Clarify parts of if-condition lowering) - rust-lang/rust#161929 (explicitly track inherent const generic args kind) - rust-lang/rust#162040 (bootstrap: stage0 to cbae9b4cae2b108f6a3d18cfe6075714bb739463) - rust-lang/rust#162063 (Switch dist-aarch64-linux to EC2 and update dist-x86_64-linux) - rust-lang/rust#161353 (Add test for parallel compiler reproducible build) - rust-lang/rust#161937 (A series of Polonius Alpha refactors) - rust-lang/rust#162051 (`rustc_feature` cleanups) - rust-lang/rust#162055 (remove `_{style}` recovery for diagnostic structs) - rust-lang/rust#162075 (Move track_caller on closures gating to attribute parsing) - rust-lang/rust#162079 (std: implement `File::fsync` for Hermit) - rust-lang/rust#162097 (Deduplicate `InstrumentFnAttr`) - rust-lang/rust#162115 (fix typo in feature documentation)
Revert "Use `drop_guard` in some places in {core,alloc,std}"
cc @panstromek @GrigorenkoPV
Reverts this PR due to perf issues, so that a fix can be verified to not affect perf. Apologies for not initially running perf; kinda tunnel-visioned "this just does the same thing" without considering the changes from non-generic functions to generic closures.
compiler-builtins subtree update Subtree update of `compiler-builtins` to rust-lang/compiler-builtins@e91a3d3. Created using https://github.com/rust-lang/josh-sync. r? @ghost
Update LLVM submodule Update to current release/23.x, which is a bit past the LLVM 23.1.0 release. Fixes rust-lang/rust#161336.
Assorted bootstrap LLVM refactors (part 4/N) Continuation on rust-lang/rust#161247. This PR completely removes handling of git changes or LLVM downloads from config parsing, and moves it into the `LlvmFromCi` step. Thanks to that, we now also allow downloading LLVM for non-host targets. There is one annoyance related to that, and that is that `download-ci-llvm` now applies to all targets for which you try to build LLVM (d'uh), but that also means that if (for whatever reason) LLVM fails to be downloaded from CI, the build will fail. So if you build for target T2 from target T1: - If you want to download T1, but build T2, that's not possible to express. - If T2 fails to be downloaded, the build fails, even if it could be built locally. I think that we mostly have four options how to deal with this: 1. Just ignore it and wait to see if someone complains. 2. Revert the change and always download only for the host target. Worked so far. However, downloading LLVM for non-host targets would be quite useful for further bootstrap improvements and refactorings, because the current logic around sysroots and libdirs is.. convoluted, to say the last, and making cross-compilation easier would help with that a lot. 3. Allow specifying `download-ci-llvm` *per target* in the target config section. So that you can say that you want to download for T1, but build for T2. 4. Make download failures non-fatal, and cause them to trigger a local build. This would also help with removing the hacky `is_ci_llvm_available_for_target` logic, which hard-codes a bunch of targets to "know" which ones offer LLVM and which don't. We could just try to download, and if the result is 404, then we print a warning and continue with building (but this is slightly orthogonal, we can do this even if we don't make LLVM build failures non-fatal). I think that 3 or 4 would be the best solution, perhaps slightly opting for 4. If we get a 404, there's no way we can download, so we build instead. If we get a different error, we still make the failed download fail the build. And only if someone has a use-case for 3, we'd add the new config. Already before this PR, we did this: ``` // If download-ci-llvm=true we also want to check that CI llvm is available b && llvm::is_ci_llvm_available_for_target(&dwn_ctx.host_target, asserts) ``` so if LLVM wasn't available, we just silently reverted from `download-ci-llvm=true` to `download-ci-llvm=false`. The 4. proposal would just generalize that, to actually check whether the LLVM files are present on the CDN or not. The problem with 4. is that you can't really set any custom build options for LLVM though, because if you also enable `download-ci-llvm`, the config sanity check will tell you to GTFO :( So we would probably need to make some changes there. r? jieyouxu
…obzol,jieyouxu bootstrap: Enable rustdoc mergeable CCI for std and internal docs Takes a different approach to rust-lang/rust#160098, where the internal docs are merged by bootstrap directly invoking rustdoc. This requires bootstrap to gather the list of metadata directories by inspecting cargo's fingerprint files (which aren't stable). The first commit is written by @camelid, but I wrote the other two. This feature is needed because: 1. The search index (that powers [web-based search](https://doc.rust-lang.org/nightly/nightly-rustc/?search=ty%20-%3E%20rustdoc%3A%3Atype)) needs to contain all of the crates in the nightly-rustc project. In particular, I'd prefer if it contained Clippy, Rustdoc, and Rustc, since those crates share type checker stuff and the ability to search all three at once is convenient. 2. For every crate that rustdoc *currently* documents, it has to load the search index from the doc output dir, and rebuild the search index with the new crate added to it. Loading the search index requires $O(\text{crates})$ work, so doing it once for every crate means we're doing $O(\text{crates}^2)$ work overall. 3. It would be more efficient, *instead*, if each crate wrote its data separately, and then the final search index was generated at the end by merging them all at once. Obviously, this would make the work linear instead of quadratic. For the record, Hoogle and Sherlodoc have a similar index-generating step. 4. We call this "Mergeable Cross-Crate-Information." Cargo stores it in the build directory, and supplies it to Rustdoc in a separate phase that runs after everything else. When we eventually stabilize this feature, it will be invisible to (most) end users. `cargo doc` will just be faster. 5. So, in order for crates to share their cross-crate info, we need them to share a build directory. 6. Tools, like Rustdoc and Cargo, don't normally share a build directory with Rustc. 7. To make them share a build directory while generating documentation, without forcing them to share a build directory while compiling, I added a new mode. --- This rustdoc feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) for `x doc src/tools` -- note that this is with the latest rustdoc perf improvements (rust-lang/rust#159854). r? @Kobzol
This updates the rust-version file to 71238e21fc55e73ab3aad8c9f79fed7a47a179e1.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@71238e2 Filtered ref: 1cf0a36 Upstream diff: rust-lang/rust@da51146...71238e2 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
12 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.