minor: Rustc pull update #20960
Merged
minor: Rustc pull update #20960
+5
−5
Conversation
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
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to 6d4b234. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Unstably constify `ptr::drop_in_place` and related methods Tracking: rust-lang/rust#109342 Supercedes: rust-lang/rust#145725 Makes methods const: * `core::ptr::drop_in_place` * `core::mem::ManuallyDrop::drop` * `core::mem::MaybeUninit::assume_init_drop` * `<[core::mem::MaybeUninit<_>]>::assume_init_drop` * `<*mut _>::drop_in_place` * `core::ptr::NonNull::drop_in_place`
…v,RalfJung Move computation of allocator shim contents to cg_ssa In the future this should make it easier to use weak symbols for the allocator shim on platforms that properly support weak symbols. And it would allow reusing the allocator shim code for handling default implementations of the upcoming externally implementable items feature on platforms that don't properly support weak symbols. In addition to make this possible, the alloc error handler is now handled in a way such that it is possible to avoid using the allocator shim when liballoc is compiled without `no_global_oom_handling` if you use `#[alloc_error_handler]`. Previously this was only possible if you avoided liballoc entirely or compiled it with `no_global_oom_handling`. You still need to avoid libstd and to define the symbol that indicates that avoiding the allocator shim is unstable.
Rollup of 12 pull requests Successful merges: - rust-lang/rust#146187 (Unstably constify `ptr::drop_in_place` and related methods) - rust-lang/rust#146503 (std: improve handling of timed condition variable waits on macOS) - rust-lang/rust#147526 (Move computation of allocator shim contents to cg_ssa) - rust-lang/rust#147630 (Bitset cleanups) - rust-lang/rust#147638 (bpf: return results larger than one register indirectly) - rust-lang/rust#147666 (Replace manual implementation with `carrying_mul_add`) - rust-lang/rust#147669 (fix missing link to `std::char` in `std` docs) - rust-lang/rust#147673 (pretty print u128 with display) - rust-lang/rust#147677 (Fewer exceptions in `span()` on parsed attributes) - rust-lang/rust#147680 (Fix ICE caused by associated_item_def_ids on wrong type in resolve diag) - rust-lang/rust#147682 (convert `rustc_main` to the new attribute parsing infrastructure) - rust-lang/rust#147683 (only check duplicates on old/unparsed attributes) r? `@ghost` `@rustbot` modify labels: rollup
Restrict sysroot crate imports to those defined in this repo. It's common to import dependencies from the sysroot via `extern crate` rather than use an explicit cargo dependency, when it's necessary to use the same dependency version as used by rustc itself. However, this is dangerous for crates.io crates, since rustc may not pull in the dependency on some targets, or may pull in multiple versions. In both cases, the `extern crate` fails to resolve. To address this, re-export all such dependencies from the appropriate `rustc_*` crates, and use this alias from crates which would otherwise need to use `extern crate`. See rust-lang/rust#143492 for an example of the kind of issue that can occur.
Remove boxes from ast list elements Less indirection should be better perf.
Use regular Vec in BitSet. That code is hot enough for the branch in all accesses to `SmallVec` to appear in profiles.
`TaskDeps` improvements Some cleanups and minor perf improvements relating to `TaskDeps`. r? `@saethlin`
rustdoc-search: stringdex 0.0.2 Two index format tweaks that reduce the size of the standard library, compiler, and wordnet dictionary when I test it. CC rust-lang/rust#146048 FF Profiler output: https://share.firefox.dev/4onH5xP Preview: https://notriddle.com/rustdoc-html-demo-12/stringdex-002/std/index.html
Pre-compute MIR CFG caches for borrowck and other analyses I was puzzled that rust-lang/rust#142390 introduces additional computations of CFG traversals: borrowck computes them, right? It turns out that borrowck clones the MIR body, so doesn't share its cache with other analyses. This PR: - forces the computation of all caches in `mir_promoted` query; - modifies region renumbering to avoid dropping that cache.
mismatched_lifetime_syntax lint refactors and optimizations I found several opportunities to return early so I'm hoping those will have a perf improvement. Otherwise, it's various refactors for simplicity.
Do not enable LLD if we don't build host code for targets that opt into it Should fix the problem mentioned in rust-lang/rust#147626 (comment). r? `@jieyouxu`
Offload host2 r? `@oli-obk` A follow-up to my previous gpu host PR. With this, I can (in theory) run a sufficiently simple Rust function on GPUs. I tested it on AMD, where the amdgcn tartget of rustc causes issues due to Addressspace castings, which might not be valid. If I (manually) fix them, I can run the generated IR on an AMD GPU. This should conceptually also work on NVIDIA or Intel. I updated the dev-guide acordingly: https://rustc-dev-guide.rust-lang.org/offload/usage.html I am unhappy with the amount of standalone functions in my offload code, so in my second commit I bundled some of the code around two structs which are Rust versions of the LLVM/Offload structs which they represent. The structs themselves only have doc comments. Since I directly lower everything to llvm-ir I didn't saw a big value in modelling the struct member variables.
Add a test for the cold attribute This adds a test for the cold attribute to verify that it actually does something, and that it applies correctly in all the positions it is expected to work.
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to 049767e. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Add a fast path for lowering trivial consts The objective of this PR is to improve compilation performance for crates that define a lot of trivial consts. This is a flamegraph of a build of a library crate that is just 100,000 trivial consts, taken from a nightly compiler: <img width="842" height="280" alt="2025-10-25-164005_842x280_scrot" src="https://github.com/user-attachments/assets/e5400aaf-03bd-4461-b905-054aa82ca60f" /> My objective is to target all of the cycles in `eval_to_const_value_raw` that are not part of `mir_built`, because if you look at the `mir_built` for a trivial const, we already have the value available. In this PR, the definition of a trivial const is this: ```rust const A: usize = 0; ``` Specifically, we look for if the `mir_built` body is a single basic block containing one assign statement and a return terminator, where the assign statement assigns an `Operand::Constant(Const::Val)`. The MIR dumps for these look like: ``` const A: usize = { let mut _0: usize; bb0: { _0 = const 0_usize; return; } } ``` The implementation is built around a new query, `trivial_const(LocalDefId) -> Option<(ConstValue, Ty)>` which returns the contents of the `Const::Val` in the `mir_built` if the `LocalDefId` is a trivial const. Then I added _debug_ assertions to the beginning of `mir_for_ctfe` and `mir_promoted` to prevent trying to get the body of a trivial const, because that would defeat the optimization here. But these are deliberately _debug_ assertions because the consequence of failing the assertion is that compilation is slow, not corrupt. If we made these hard assertions, I'm sure there are obscure scenarios people will run into where the compiler would ICE instead of continuing on compilation, just a bit slower. I'd like to know about those, but I do not think serving up an ICE is worth it. With the assertions in place, I just added logic around all the places they were hit, to skip over trying to analyze the bodies of trivial consts. In the future, I'd like to see this work extended by: * Pushing detection of trivial consts before MIR building * Including DefKind::Static and DefKind::InlineConst * Including consts like `_1 = const 0_usize; _0 = &_1`, which would make a lot of promoteds into trivial consts * Handling less-trivial consts like `const A: usize = B`, which have `Operand::Constant(Const::Unevaluated)`
Skip codegen_crate call in check mode This way we don't have to spawn the coordinator thread. Some errors will no longer be emitted with this in check mode. For example the check that `-Ctarget-cpu` is passed on targets that need this. Suggested by `@saethlin`
Do not lifetime-extend array/slice indices When lowering non-overloaded indexing operations to MIR, this uses the temporary lifetime of the index expression for the index temporary, rather than applying the temporary lifetime of the indexing operation as a whole to the index. For example, in ```rust let x = &xs[i]; ``` previously, the temporary containing the result of evaluating `i` would live until the end of the block due to the indexing operation being [lifetime-extended](https://doc.rust-lang.org/nightly/reference/destructors.html#temporary-lifetime-extension). Under this PR, the index temporary only lives to the end of the `let` statement because it uses the more precise temporary lifetime of the index expression. I don't think this will affect semantics in an observable way, but the more precise `StorageDead` placement may slightly improve analysis/codegen performance. r? mir
Update cc-rs to 1.2.39 For my purposes, contains fixes when compiling the Rust compiler for Arm64EC. Checked the commits since 1.2.16, and I don't see anything else that may affect Rust? `find-msvc-tools` was also factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of the Rust compiler).
perf: removed unnecessary let for return only in layout.rs perf: removed unnecessary let for return only
Adjust successor iterators. Because rust-lang/rust#148054 was a slight perf regression. The problem was seemingly because this iterator structure: ``` slice_iter.chain(Option_iter.chain(Option_iter)) ``` changed to this: ``` slice_iter.chain(Option_iter).chain(Option_iter) ``` The commit also tweaks the `slice_iter` part, changing `into_iter` to `iter` and using `[]` instead of `(&[])`, for conciseness and consistency. r? `@saethlin`
smart pointer (try_)map Tracking issue: rust-lang/rust#144419
Return `Option` from `exact_div` and inherit overflow checks According to rust-lang/rust#139911 (comment), `exact_div` should return `Option::None` if `self % rhs != 0`, panic if `rhs == 0`, and handle overflow conditionally (panic in debug, wrap in release). rust-lang/rust#147771 should rename `exact_div` to `div_exact`.
Constify Range functions Constify various `Range` traits, functions, and implementations
Add `is_ascii` function optimized for LoongArch64 for [u8] Similar to x86_64, on LoongArch64 we use the `vmskltz.b` instruction to test the high bit in a lane. For longer input cases, the performance improvement is significant. For unaligned cases close to 32 bytes in length, there's some regression, but it seems acceptable. | core benches (MB/s) | Before | After | % | |--------------------------------------------------------|--------|--------|---------| | ascii::is_ascii::short::case00_libcore | 1000 | 1000 | 0.00 | | ascii::is_ascii::medium::case00_libcore | 8000 | 8000 | 0.00 | | ascii::is_ascii::long::case00_libcore | 183947 | 436875 | +137.50 | | ascii::is_ascii::unaligned_head_medium::case00_libcore | 7750 | 2818 | -63.64 | | ascii::is_ascii::unaligned_head_long::case00_libcore | 317681 | 436812 | +37.50 | | ascii::is_ascii::unaligned_tail_medium::case00_libcore | 7750 | 3444 | -55.56 | | ascii::is_ascii::unaligned_tail_long::case00_libcore | 155311 | 436812 | +181.25 | | ascii::is_ascii::unaligned_both_medium::case00_libcore | 7500 | 3333 | -55.56 | | ascii::is_ascii::unaligned_both_long::case00_libcore | 174700 | 436750 | +150.00 |
…ulacrum std: don't leak the thread closure if destroying the thread attributes fails The comment about double-free is wrong – we can safely drop both the thread attributes and the thread closure. Here, I've used `DropGuard` for the attributes and moved the `Box::into_raw` to just before the `pthread_create`.
Ignore unix socket related tests for VxWorks Unix Sockets are not implemented in VxWorks, and therefore, ignore testcases related to UnixDatagram, UnixListener and UnixStream.
…oieni Generalize branch references It should be safe to merge this before the rename, and I'd like to do that, so we can test if beta/stable PRs work. r? ``@marcoieni``
Fix suggestion when there were a colon already in generics Finally found time to fix rust-lang/rust#144215 I don't feel like this `colon_flag` is perfect solution and that it can be refactored, but I'd say that this is pretty good as it, I was tried to refactor this a little, but the thing is the scope where `param.colon_span` lives is very limited, so there is not much time to check was there colon or not, I tried to rewrite this into more functional style to address this, but it becomes way more unreadable than this one or even less performant, maybe some comments could push readability of this fix further, maybe a comment for enum or `colon_flag`?
Rollup of 7 pull requests Successful merges: - rust-lang/rust#146573 (Constify Range functions) - rust-lang/rust#146699 (Add `is_ascii` function optimized for LoongArch64 for [u8]) - rust-lang/rust#148026 (std: don't leak the thread closure if destroying the thread attributes fails) - rust-lang/rust#148135 (Ignore unix socket related tests for VxWorks) - rust-lang/rust#148211 (clippy fixes and code simplification) - rust-lang/rust#148395 (Generalize branch references) - rust-lang/rust#148405 (Fix suggestion when there were a colon already in generics) r? `@ghost` `@rustbot` modify labels: rollup
This updates the rust-version file to c5dabe8cf798123087d094f06417f5a767ca73e8.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: c5dabe8cf798123087d094f06417f5a767ca73e8 Filtered ref: 3214048 Upstream diff: rust-lang/rust@fb24b04...c5dabe8 This merge was created using https://github.com/rust-lang/josh-sync.
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
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.