Repository navigation
Rustc pull update - #3043
Merged
Merged
Rustc pull update#3043
Conversation
Apply LTO to Cranelift and GCC codegen backends Before we didn't use the LTO config for them at all.
add relnotes 1.99.0 r? mark-simulacrum cc @rust-lang/release
…=Darksonn const and NonZero impl for clamp_magnitude() This PR is implementing the latest proposed changes in Issue rust-lang/rust#148519, making the clamp_magnitude() functions const for all floating point and integer types, as well as adding a clamp_magnitude() to NonZero<$Int>, taking a NonZero<$UInt> as limit parameter.
Don't use the metadata based crate_hash for rustdoc runs When a metrics dir is provided for a rustdoc invocation, the crate hash is used to generate the file name for the metrics. Prior to this change, `tcx.needs_metadata()` mistakenly returned true, so the crate_hash query would attempt to read the SVH created as a side effect of the metadata generation. Since metadata is not generated for rustdoc, that SVH was not present, which triggered the ICE. This PR marks `tcx.needs_metadata()` as false for rustdoc runs, which causes the crate_hash query to use the fallback HIR based hash. One caveat: rust-lang/rust#154724 made the HIR based hash simpler under the assumption that it would only be used for things like dylibs. Specifically, it removed resolutions.visibilities_for_hashing, debugger_visualizers and source_file_names. The latter two are irrelevant for rustdoc, but the first is potentially relevant. However, the hash only has to change when the metrics output it names would change, and the output it names is a list of enabled features, which visibility can't affect. LLM: Claude was used to generate the tests that reproduce the issue. Fixes: rust-lang/rust#163426 Regression introduced in rust-lang/rust#154724 Related to rust-lang/rust#94878
make mips64 `Complex` GCC-compatible tracking issue: rust-lang/rust#154023 This implementation is compatible with GCC and Clang >= 24, see llvm/llvm-project#212109. This implementation has been validated versus GCC and Clang 24 with abi-cafe.
Don't build format string suggestions from `concat!` offsets Fixes rust-lang/rust#156101 When a format string does not come directly from a string literal in the source, e.g. when it is produced by `concat!`, the parser's inner offsets are relative to the expanded string rather than to the source. The primary error span and the `RemoveRawIdent` suggestion already check `is_source_literal` before calling `fmt_span.from_inner`, but the `UsePositional`, `ReorderFormatParameter` and `AddMissingColon` suggestions did not. As a result, these suggestions could point into the middle of a multibyte character and ICE when rendered, or suggest a bogus argument copied from unrelated source text. Only emit them when the format string is a source literal, like the other suggestions do. For example, before this change `UsePositional` took `at!` from the `concat!` invocation as the captured argument, replaced it with `0`, and suggested passing `at!` as an argument: ``` help: consider using a positional formatting argument instead | 2 - format_args!(concat!("{}{a.b}", "")); 2 + format_args!(conc0("{}{a.b}", ""), at!); ``` The crash test is moved to `tests/ui/fmt`, with cases covering each of these suggestions.
…risDenton Update expect messages in library/std/src/os/unix/net/ following Rust's `expect` guidance Related issue: rust-lang/rust#159751 This PR updates `expect` messages in `library/std/src/os/unix/net` in accordance with the guidance.
…anBrouwer Miscellaneous attr error stuff Some small improvements I made while working on something bigger (that didn't work out). Details in individual commits. r? @JonathanBrouwer
x86 and x86_64: cleanup some callconv code Some cleanup work in the x86 and x86_64 callconv code. The x86 portion is in preparation for `-Zregparam`, cc - rust-lang/rust#131749 - rust-lang/rust#161027 Best reviewed commit-by-commit. There should be no functional changes.
Cast cleanups At one point I was looking at merging `ast::IntTy` and `ast::UintTy` into a single type. In the end I decided against that, but I did find some related code, mostly involving casts, that deserved some cleanups. Details in individual commits. r? @oli-obk
Document `Result` case for the `arena_cache` query modifier r? @Zalathar
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to be8854f. Created using https://github.com/rust-lang/josh-sync. r? @ghost
remove dead cfg_select! arm I accidentally added this in rust-lang/rust#158936. Mea culpa 😅
Rollup of 20 pull requests Successful merges: - rust-lang/rust#163279 (const and NonZero impl for clamp_magnitude()) - rust-lang/rust#163081 (Provide more context on "not general enough" error) - rust-lang/rust#163455 (Don't use the metadata based crate_hash for rustdoc runs) - rust-lang/rust#159798 (Attribute documentation for cfg_attr) - rust-lang/rust#162921 (make mips64 `Complex` GCC-compatible) - rust-lang/rust#163368 (Don't build format string suggestions from `concat!` offsets) - rust-lang/rust#163375 (Update expect messages in library/std/src/os/unix/net/ following Rust's `expect` guidance) - rust-lang/rust#163470 (Miscellaneous attr error stuff) - rust-lang/rust#163489 (expose Rc::is_unique) - rust-lang/rust#163492 (x86 and x86_64: cleanup some callconv code) - rust-lang/rust#163496 (cycle handling: mirror old solver) - rust-lang/rust#163509 (Use more default field values in `Resolver`) - rust-lang/rust#163519 (Forbid `Reborrow` impls for types with destructors) - rust-lang/rust#163520 (Cast cleanups) - rust-lang/rust#163524 (Document `Result` case for the `arena_cache` query modifier) - rust-lang/rust#163546 (PassWrapper: adapt for new PassPlugin load method) - rust-lang/rust#163551 (Add libs-nominated triagebot config) - rust-lang/rust#163559 (Suggest `#[unsafe(no_mangle)]` for entry points in `no_std` binaries) - rust-lang/rust#163564 (rustc-dev-guide subtree update) - rust-lang/rust#163568 (remove dead cfg_select! arm)
Clippy subtree update r? @Manishearth `Cargo.lock` update due to Clippy version bump
add fast path to generalization https://github.com/rust-lang/rust/blob/e19d321c06479c6fd77533582b0d5a86651f1be3/tests/ui/traits/issue-91949-hangs-on-recursion.rs ends up spending a lot of time in generalization: This test takes 7.8s with this branch, 47s without it. Generalization is just a noop during monomorphization. r? types
Having two `run_compiler` functions has always been confusing and not necessary at all, as they perform fairly different functions. Even more so because `rustc_driver::run_compiler` calls to `rustc_interface::run_compiler`. So it seems like a recursive function when it really isn't.
Emit llvm dereferenceable in more cases on newer LLVM versions On llvm >= 23 emit `dereferenceable` even without `nofree`, since llvm/llvm-project#204795 makes `dereferenceable` act "at a point" / not imply `nofree`. Additionally restrict `dereferenceable` to `&Freeze` / `&mut Unpin` / `Box<Unpin, _>` only (this is only relevant for `llvm >= 23` as otherwise `!Freeze`/`!Unpin` suppress `nofree` and as such `dereferenceable`). r? nikic I thought this will be a bit harder change, but since your refactoring in rust-lang/rust#156281 it's actually trivial ^^' Draft because I don't think this can be tested prior to LLVM update. I'm also not sure if the version check I did is the appropriate one... cc @RalfJung
…bzol Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs" Reverts rust-lang/rust#162339 Re-applies rust-lang/rust#161716 and rust-lang/rust#162318 Since a new beta has been released between then and now, the fix applied in rust-lang/rust#162346 is in beta, so the code should work. r? @jieyouxu
…, r=tgross35 Add mul_add_relaxed methods for floating-point types Implements mul_add_relaxed for f16, f32, f64, and f128, which computes (self * a) + b with relaxed precision semantics. Unlike mul_add which guarantees a fused operation, this variant allows the compiler to choose between fused or separate operations based on target performance. This fills the gap between the precision-guaranteed mul_add and the fully-optimizable algebraic operators, providing target-specific optimization while maintaining reasonable floating-point semantics. Tracking issue: rust-lang/rust#151770 try-job: dist-i586-gnu-i586-i686-musl
Miri can do dirfd now So let's remove some special-casing from the standard library. Fixes rust-lang/miri#5327
…nnethercote Improve `DocStrings` perf Follow-up of rust-lang/rust#162862. r? ghost
Fix `TypeOutlives` fast-path > Oh, the fast path is scuffed here. So, I feel fairly confident that we can encounter cases where stalled_on is wrong due to region vars without there being a bug, as in, your change is correct and desirable, but this specific test is just a bug in the fast path: > > `<MaybeVerify as Service<?infer>>::Future: 'static` should simply not be considered stalled. What's the cost of either entirely removing this trivially_stalled_on fast path or fixing it to bail when encountering non-rigid aliases > > This change is correct. Please separately do a PR to fix the type-outlives fastpath :blush: _Originally posted by @lcnr in rust-lang/rust#162782 (comment) The first perf-run result is for always returning `Outcome::NoFastPath` on any infer var and the second one is for the current HEAD. We shouldn't stall the outlives goal if the goal contains a non-rigid alias even though the goal contains a non-region infer. Non-fast path will normalize that non-rigid alias and that make the evaluation progress, and I think in theory the fast path shouldn't make observable difference outside the solver. I'm not entirely sure on disabling fast path only in the presence of non-rigid opaques instead of disabling it entirely for non-region infer, but.. - It's no-less-correct than the status quo - It roughly matches the actual non-fast path: https://github.com/rust-lang/rust/blob/dba8825fe50879b22129271fb865944e384f7cce/compiler/rustc_next_trait_solver/src/solve/mod.rs#L128-L129 - The later has some perf impact hard to ignore for `typenum` I couldn't conjure up any case fixed by this PR other than the one in rust-lang/rust#162782 😅 r? lcnr
…ochenkov Several small span improvements Limit changes: - Increase `MAX_CTXT`: it is currently `0b0111_1111_1111_1110` (~15 bits). But it only needs to be distinguishable from `CTXT_INTERNED_MARKER` (all 1s). So we can increase it to `0b1111_1111_1111_1110` (~16 bits). The old limit is rarely reached; the `uom` crate is an exception (it has 39k contexts) and we see a 1-2% instruction count reduction when building it. (This value was incorrectly reduced from ~16 bits to ~15 bits in e525e4f10a8 by me; apologies!) Renamings: - Rename `MAX_CTXT` as `MAX_CTXT_OR_PARENT` because it also relates to the parent field. - Remove the `BASE_` prefix from `BASE_LEN_INTERNED_MARKER` because it doesn't mean anything. Comments: - Update parts of the comment that predate the addition of the `parent` field, such as the frequency measurements. (In incremental builds, 20-40% internment due to non-root context and non-zero parent is common.) - Slightly clarify the meanings of the fields in the different forms, and add a paragraph quickly explaining which specific values distinguish the four forms. r? @petrochenkov
Reorganise reflection intrinsics Trivial refactor moving some things around. We got a fair amount of intrinsics for reflection now with more on the way. At this point it's worth it to reorganize things a little. This prefixes them with `type_id_` (`TypeId` is the entry point for _nearly_ all of reflection) and moves their declaration into its own module (`core::intrinsics::reflection`). Possible contentious is the move of the `type_id` intrinsic which has existed for a while and was previously at `core::intrinsics::type_id`. It is still unstable and as far as I am aware intrinsics should really not be relied upon by users. I've decided to leave the `field_representing_field` (name, offset, actual_type_of) where they are since those where not created for reflection and will be changed in the future (see: rust-lang/rust#162127). r? oli-obk
fix `ValidateBoundVars` `ControlFlow::Break` is just wrong. We want to visit later types even if we skip the current one. The `t.outer_exclusive_binder() <= self.binder_index` check is more subtle. See the flag computation https://github.com/rust-lang/rust/blob/29df41c47187f735942d13900b784962ef1bc140/compiler/rustc_type_ir/src/flags.rs#L217-L218 It is the exclusive binder. The first binder for which there exist no bound vars. This is subtle and was found while asking an LLM to help with perrrrf, only for me to then be confused for 10 min while checking whether this is right :< r? types
…rypoint, r=oli-obk Rename `rustc_driver::run_compiler` to `compiler_entrypoint` Having two `run_compiler` functions has always been confusing and not necessary at all, as they perform fairly different functions. Even more so because `rustc_driver::run_compiler` calls to `rustc_interface::run_compiler`. So it seems like a recursive function when it really isn't.
Remove variants from `feature-gate-autodiff-use` test Both the stable and nightly variants were the same; the test didn't actually test what it thought, because compiletest enables `RUSTC_BOOTSTRAP=1` unconditionally. CC @ZuseZ4 r? jieyouxu
…uwer Rollup of 14 pull requests Successful merges: - rust-lang/rust#163582 (Reapply "bootstrap: Enable rustdoc mergeable CCI for std and internal docs") - rust-lang/rust#151793 (Add mul_add_relaxed methods for floating-point types) - rust-lang/rust#162782 (Fix rustdoc ICE caused by mishandling of ambiguity errors) - rust-lang/rust#163010 (Miri can do dirfd now) - rust-lang/rust#163535 (Improve `DocStrings` perf) - rust-lang/rust#163576 (Fix `TypeOutlives` fast-path) - rust-lang/rust#163587 (Several small span improvements) - rust-lang/rust#163603 (Reorganise reflection intrinsics) - rust-lang/rust#163612 (fix `ValidateBoundVars`) - rust-lang/rust#163632 (bump rustc-build-sysroot) - rust-lang/rust#163635 (Revert note about signum of NaN) - rust-lang/rust#163644 (Add mailmap entry) - rust-lang/rust#163647 (Rename `rustc_driver::run_compiler` to `compiler_entrypoint`) - rust-lang/rust#163651 (Remove variants from `feature-gate-autodiff-use` test)
explicitly handle tests that pass with -Znext-solver these are all UI tests which pass with the new solver and fail with old. Using explicit revisions here. Editing some of them to actually test what they should 😁
Send -fno-lto when linker plugin LTO is not requested to avoid having GCC do LTO when using rustc_codegen_gcc More info on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Add.20linker.20flag.20from.20the.20codegen/near/375045533). cc @bjorn3
Update the minimum external LLVM to 22 With this change, we'll have stable support for LLVM 22 and 23. For reference, the previous increase to LLVM 21 was rust-lang/rust#153684. cc @rust-lang/wg-llvm @durin42 r? nikic
…=clarfonthey
Docs - type guarantees update
**Content:**
- Pin::map_unchecked | Safety section update
- String::reserve, String::reserve_exact | Panic section update
- Saturating | Introduce Layout section
- Fix typos
**Questions:**
1. This proposes to update String reserve methods docs:
> Panics if the new capacity overflows [`usize`].
->
> Panics if the new capacity exceeds [`isize::MAX`] bytes.
There are a few other types that are based on Vec and offer similar reserve API (like BinaryHeap).
Should they be updated, too?
ACP: ~~rust-lang/libs-team#482 [not required]
…alfJung Distinguish `repr(C)` ZSTs from others in ABI compatibility rules FCP: rust-lang/rust#157973 (comment) (Split out from compiler implementation in rust-lang/rust#156112) Some C ABIs pass and return ZSTs by pointer. But `()` should never be returned by pointer, as it must match `void`. To account for this, we have to weaken the present guarantee of "any two types with size 0 and alignment 1 are ABI-compatible" to exclude `repr(C)`. [t-lang nomination summary comment](rust-lang/rust#157973 (comment)) Fixes rust-lang/unsafe-code-guidelines#552; see also rust-lang/rust#78586, rust-lang/rust#155299. Also related to rust-lang/rust#155984. @rustbot label T-lang A-ABI needs-fcp
preserve overflow in builtin Field candidates preserve overflow from the builtin Field candidate instead of treating it as `NoSolution` the Sized requirements are now evaluated inside the candidate probe and coherence correctly rejects overlapping impls when evaluation overflows. fixes rust-lang/rust#162125
…they intrinsics: Rename `abort` to `abort_immediate` The semantics of `intrinsics::abort()` are closer to what we have unstably as `abort_immediate()` than to `process::abort()` or `libc::abort()`. Rename it to make more clear that the intrinsic is more of an intentional crash with platform-specific behavior than what `libc::abort()` tries to be (i.e. raising `SIGABRT`). If desired, a new intrinsic like `abort_gracefully` could be introduced that performs platform-specific behavior. This would more cleanly unblock rust-lang/rust#149780. See also discussion at the tracking issue for `immediate_abort` rust-lang/rust#154601.
avoid trivial `fn map_bound` validations
when compiling `zerocopy` a lot of time is spent simply checking the bound vars in `Clause::kind` because it does
```rust
self.0.internee.map_bound(|kind| match kind {
PredicateKind::Clause(clause) => clause,
_ => unreachable!(),
})
```
let's make performance with `debug_assertions` a bit better:
`zerocopy` with `-Znext-solver`:
```
16884862 counts
( 1) 12189626 (72.2%, 72.2%): Binder::map_bound called at compiler/rustc_middle/src/ty/predicate.rs:174:25
( 2) 1853971 (11.0%, 83.2%): Binder::map_bound called at compiler/rustc_type_ir/src/binder.rs:89:14
( 3) 1443803 ( 8.6%, 91.7%): Binder::map_bound called at compiler/rustc_type_ir/src/inherent.rs:493:14
( 4) 572570 ( 3.4%, 95.1%): Binder::map_bound called at compiler/rustc_type_ir/src/predicate.rs:234:14
( 5) 272733 ( 1.6%, 96.7%): Binder::map_bound called at compiler/rustc_type_ir/src/inherent.rs:507:14
( 6) 184934 ( 1.1%, 97.8%): Binder::map_bound called at compiler/rustc_middle/src/ty/predicate.rs:523:14
( 7) 183998 ( 1.1%, 98.9%): Binder::map_bound called at compiler/rustc_type_ir/src/predicate.rs:251:14
```
`zerocopy` with `-Znext-solver=no`
```
13476410 counts
( 1) 9906183 (73.5%, 73.5%): Binder::map_bound called at compiler/rustc_middle/src/ty/predicate.rs:174:25
( 2) 2107825 (15.6%, 89.1%): Binder::map_bound called at compiler/rustc_type_ir/src/binder.rs:89:14
( 3) 376524 ( 2.8%, 91.9%): Binder::map_bound called at compiler/rustc_type_ir/src/inherent.rs:493:14
( 4) 321976 ( 2.4%, 94.3%): Binder::map_bound called at compiler/rustc_type_ir/src/predicate.rs:251:14
( 5) 262305 ( 1.9%, 96.3%): Binder::map_bound called at compiler/rustc_middle/src/ty/predicate.rs:523:14
( 6) 84143 ( 0.6%, 96.9%): Binder::map_bound called at compiler/rustc_infer/src/infer/outlives/verify.rs:49:47
( 7) 83876 ( 0.6%, 97.5%): Binder::map_bound called at compiler/rustc_infer/src/traits/mod.rs:183:24
```
compiling `std`:
```
32803629 counts
( 1) 12234204 (37.3%, 37.3%): Binder::map_bound called at compiler/rustc_type_ir/src/binder.rs:89:14
( 2) 9624749 (29.3%, 66.6%): Binder::map_bound called at compiler/rustc_middle/src/ty/predicate.rs:174:25
( 3) 3805442 (11.6%, 78.2%): Binder::map_bound called at compiler/rustc_type_ir/src/inherent.rs:493:14
( 4) 2542468 ( 7.8%, 86.0%): Binder::map_bound called at compiler/rustc_type_ir/src/predicate.rs:234:14
( 5) 1229480 ( 3.7%, 89.7%): Binder::map_bound called at compiler/rustc_middle/src/ty/predicate.rs:523:14
( 6) 1176716 ( 3.6%, 93.3%): Binder::map_bound called at compiler/rustc_type_ir/src/predicate.rs:251:14
( 7) 385823 ( 1.2%, 94.5%): Binder::map_bound called at compiler/rustc_type_ir/src/inherent.rs:507:14
```
Could spend more effort to avoid the validation in trivial `Binder::fold_with`, but that's not worth it I think.
cc https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/casual.20chat.20and.20support/near/628479010
yeet compare-mode-coherence `-Znext-solver=coherence` is stable
Add a single-entry parent `SpanData` cache For use in encoding, decoding, and stable hashing. It's a decent performance win on a number of benchmarks. r? @oli-obk
…uwer Rollup of 9 pull requests Successful merges: - rust-lang/rust#163655 (explicitly handle tests that pass with -Znext-solver) - rust-lang/rust#159924 (Send -fno-lto when linker plugin LTO is not requested to avoid having GCC do LTO when using rustc_codegen_gcc) - rust-lang/rust#163572 (Update the minimum external LLVM to 22) - rust-lang/rust#129822 (Docs - type guarantees update) - rust-lang/rust#157973 (Distinguish `repr(C)` ZSTs from others in ABI compatibility rules) - rust-lang/rust#162332 (preserve overflow in builtin Field candidates) - rust-lang/rust#163574 (intrinsics: Rename `abort` to `abort_immediate`) - rust-lang/rust#163638 (avoid trivial `fn map_bound` validations) - rust-lang/rust#163660 (yeet compare-mode-coherence)
rustfmt subtree update Subtree update of `rustfmt` to rust-lang/rustfmt@677b954. Created using https://github.com/rust-lang/josh-sync. ### Relnotes worthy (1.101 cycle) https://github.com/rust-lang/rustfmt/pulls?q=is%3Apr+state%3Aclosed+merged%3A2026-09-22..2026-09-30 (excluding the v1.11.0 release prep PR): * rust-lang/rustfmt#7115 (config search behavior) * rust-lang/rustfmt#7095 (potentially breaking) * rust-lang/rustfmt#6396 * rust-lang/rustfmt#7152 (but that's a fix for beta-regression) ### Needs beta backport (targetting 1.100) I will make a beta-targetting cherry-pick with the following PR * rust-lang/rustfmt#7152 --- r? @ytmimi
Update LLVM submodule to latest release/23.x branch Updates to rust-lang/llvm-project#200. This includes LLVM 23.1.2, and a bunch of commits from LLVM 23.1.3 (which is yet unreleased). In particular, it includes llvm/llvm-project#224185 (llvm/llvm-project#222721), which should fix rust-lang/rust#162928. r? nikic @bors rollup=never
Optimize Cranelift with PGO Opening for perf. experiments.
This updates the rust-version file to 260f1acad9d7f70b5b56a636a9dc5a7f76150417.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Previous upstream ref: rust-lang/rust@7d2cd0f New upstream ref: rust-lang/rust@260f1ac Filtered ref: 87462f1 Upstream diff: rust-lang/rust@7d2cd0f...260f1ac 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
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.
Latest update from rustc.