Rustc pull update #1954
Merged
Rustc pull update #1954
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
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: caccb4d0368bd918ef6668af8e13834d07040417 Filtered ref: 0f345ed05d559bbfb754f1403b16199366cda2e0 Upstream diff: rust-lang/rust@21a19c2...caccb4d This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
fix SCIP panicking due to salsa not attaching
Remove non-ns version of impl_self_ty and impl_trait
Fix fixes for unused raw variables
Fix applicable on if-let-chain for invert_if
…-ret Add let-chain support for convert_to_guarded_return
Add const parameter keyword completion
Add cfg_attr predicate completion
Fix precedence parenthesis for replace_arith_op
Add applicable on bang `!` for apply_demorgan
Allow `&raw [mut | const]` for union field
…cro-by-example Fix negative integer literals in const generics in declarative macro context
fix: Prevent rustup from automatically installing toolchains
Add ide-assist: generate blanket trait impl
Add ide-assist: flip_range_expr
Fix shorthand field pat for destructure_tuple_binding
Fix extract multiple item in impl for extract_module
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: c5dabe8cf798123087d094f06417f5a767ca73e8 Filtered ref: 3214048a4d271548c85aae8ffc5f28ec73719235 Upstream diff: rust-lang/rust@fb24b04...c5dabe8 This merge was created using https://github.com/rust-lang/josh-sync.
add SliceIndex wrapper types Last and Clamp<Idx> Tracking issue: rust-lang/rust#146179
stdarch subtree update Subtree update of `stdarch` to b5c1645. Created using https://github.com/rust-lang/josh-sync. r? `@sayantn` --- Only the last 2 commits contain manual changes to some incorrect miri tests. The remainder is mechanical, and just synchronizes changes from stdarch.
Rollup of 3 pull requests Successful merges: - rust-lang/rust#146260 (add SliceIndex wrapper types Last and Clamp<Idx>) - rust-lang/rust#148394 (Make explicit that `TypeId`'s layout and size are unstable) - rust-lang/rust#148402 (stdarch subtree update) r? `@ghost` `@rustbot` modify labels: rollup
tests: activate misspelled `gdb-check` in `function-arg-initialization.rs` In 9253e1206e91f5bd7 a bunch of `gdbr-check` (for `rust-gdb`) directives and `gdbg-check` (for plain `gdb`) directives were added. But in two places the author accidentally wrote `gdbt-check` instead (`t` is next to `r` on the keyboard). This commit fixes that typo. rust-lang/rust#129218 later renamed `gdbr-check` to just `gdb-check` which is why we rename to `gdb-check` directly. The test still passes locally for me after the change, but fails if I change the `gdb-check` checks to check for some other string, so the check seems to still perform its intended function. Note that we need to add a `std::hint::black_box()` to avoid $4 = <optimized out> prints on at least `aarch64-gnu-llvm-20-1`. After this there are no more instances of the string `gdbt` in the code base: ```console $ git grep gdbt ``` try-job: dist-i586-gnu-i586-i686-musl
…ouwer,davidtwco Add LLVM range attributes to slice length parameters It'll take a bunch more work to do this in layout -- because of cycles in `struct Foo<'a>(&'a Foo<'a>);` -- so until we figure out how to do that well, just look for slices specifically and add the proper range for the length.
minor: Rustc pull update
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@51af7a3. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Tweak output of missing lifetime on associated type Follow up to rust-lang/rust#135602. Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide. ``` error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration --> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18 | 7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>; | ^^^^ lifetimes do not match type in trait | ::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5 | 292 | type IntoIter: Iterator<Item = Self::Item>; | ------------------------------------------ lifetimes in impl do not match this type in trait ``` Given an associated item that needs a named lifetime, look at the enclosing `impl` item for one. If there is none, look at the self type and the implemented trait to see if either of those has an anonimous lifetime. If so, suggest adding a named lifetime. ``` error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type --> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17 | LL | type Item = &T; | ^ this lifetime must come from the implemented type | help: add a lifetime to the impl block and use it in the self type and associated type | LL ~ impl<'a> IntoIterator for &'a S { LL ~ type Item = &'a T; | ``` Move the previous long message to a note and use a shorter primary message: ``` error: missing lifetime in associated type --> $DIR/missing-lifetime-in-assoc-type-1.rs:9:17 | LL | impl<'a> IntoIterator for &S { | ---- there is a named lifetime specified on the impl block you could use ... LL | type Item = &T; | ^ this lifetime must come from the implemented type | note: in the trait the associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type --> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL help: consider using the lifetime from the impl block | LL | type Item = &'a T; | ++ ``` r? `@Nadrieril`
…rk-Simulacrum std_detect: Support run-time detection on OpenBSD using elf_aux_info
Implement SIMD funnel shifts in const-eval/Miri Split off from rust-lang/rust#147520 with just this change for easier review r? ```@RalfJung```
Stabilise `as_array` in `[_]` and `*const [_]`; stabilise `as_mut_array` in `[_]` and `*mut [_]`. Tracking issue: rust-lang/rust#133508 Closes: rust-lang/rust#133508 This PR stabilises the `as_array` and `as_mut_array` associated functions from the `core_slice_as_array` feature gate: ```rust // core::slice impl<T> [T] { pub const fn as_array<const N: usize>(&self) -> Option<&[T; N]>; pub const fn as_mut_array<const N: usize>(&mut self) -> Option<&mut [T; N]>; } // core::ptr impl<T> *const [T] { pub const fn as_array<const N: usize>(self) -> Option<*const [T; N]>; } impl<T> *mut [T] { pub const fn as_mut_array<const N: usize>(self) -> Option<*mut [T; N]>; } ``` It also updates the feature gates and tracking issues for all items associated with the previous `slice_as_array` tracking issue (including these four that are being stabilised). ~~FCP missing.~~
update isolate_highest_one for NonZero<T> ## Rationale Let `x = self` and `m = (((1 as $Int) << (<$Int>::BITS - 1)).wrapping_shr(self.leading_zeros()))` Then the previous code computed `NonZero::new_unchecked(x & m)`. Since `m` has exactly one bit set (the most significant 1-bit of `x`), `(x & m) == m`. Therefore, the masking step was redundant. The shift is safe and does not need wrapping because: * `self.leading_zeros() < $Int::BITS` because `self` is non-zero. * The result of `unchecked_shr` is non-zero, satisfying the `NonZero` invariant. if wrapping happens we would be violating `NonZero` invariants. why this micro optimization? the old code was suboptimal it duplicated `$Int`’s isolate_highest_one logic instead of delegating to it. Since the type already wraps `$Int`, either delegation should be used for clarity or, if keeping a custom implementation, it should be optimized as above.
…eGomez rustdoc: Properly highlight shebang, frontmatter & weak keywords in source code pages and code blocks Before | After ---|--- <img width="517" height="532" alt="Screenshot 2025-10-28 at 23-21-02 pre rs - source" src="https://github.com/user-attachments/assets/5026761f-c604-4bcc-a699-9e75eb73dff6" /> | <img width="499" height="531" alt="Screenshot 2025-10-28 at 23-21-51 pre rs - source" src="https://github.com/user-attachments/assets/cc8c65e7-e3ad-4e20-a2c3-2623cf799093" />
Fix rust-by-example spanish translation A spanish translation was added in rust-lang/rust-by-example#1910, but the upstream integration was never added. ```@marioidival,``` I assume you intended for this to go live?
… r=JonathanBrouwer Fix suggestion for returning async closures Fixes rust-lang/rust#148493
…ofek [rustdoc] Replace `print` methods with functions to improve code readability We have a lot of `print` methods, making it quite tricky to know what the types we're manipulating are. We did something similar with `Clean` trait a few years ago (the first PR was rust-lang/rust#99638, followed by a lot of them). Each commit replaces one type for easier review. r? `````@yotamofek`````
…onathanBrouwer re-use `self.get_all_attrs` result for pass indirectly attribute Could be a fix for a potential performance regression reported here rust-lang/rust#144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor. r? ````@JonathanBrouwer```` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)
mgca: Add ConstArg representation for const items tracking issue: rust-lang/rust#132980 fixes rust-lang/rust#131046 fixes rust-lang/rust#134641 As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item. To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR. We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
Rollup of 10 pull requests Successful merges: - rust-lang/rust#145656 (Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro) - rust-lang/rust#147024 (std_detect: Support run-time detection on OpenBSD using elf_aux_info) - rust-lang/rust#147534 (Implement SIMD funnel shifts in const-eval/Miri) - rust-lang/rust#147540 (Stabilise `as_array` in `[_]` and `*const [_]`; stabilise `as_mut_array` in `[_]` and `*mut [_]`.) - rust-lang/rust#147686 (update isolate_highest_one for NonZero<T>) - rust-lang/rust#148230 (rustdoc: Properly highlight shebang, frontmatter & weak keywords in source code pages and code blocks) - rust-lang/rust#148555 (Fix rust-by-example spanish translation) - rust-lang/rust#148556 (Fix suggestion for returning async closures) - rust-lang/rust#148585 ([rustdoc] Replace `print` methods with functions to improve code readability) - rust-lang/rust#148600 (re-use `self.get_all_attrs` result for pass indirectly attribute) r? `@ghost` `@rustbot` modify labels: rollup
Add `overflow_checks` intrinsic This adds an intrinsic which allows code in a pre-built library to inherit the overflow checks option from a crate depending on it. This enables code in the standard library to explicitly change behavior based on whether `overflow_checks` are enabled, regardless of the setting used when standard library was compiled. This is very similar to the `ub_checks` intrinsic, and refactors the two to use a common mechanism. The primary use case for this is to allow the new `RangeFrom` iterator to yield the maximum element before overflowing, as requested [here](rust-lang/rust#125687 (comment)). This PR includes a working `IterRangeFrom` implementation based on this new intrinsic that exhibits the desired behavior. [Prior discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Ability.20to.20select.20code.20based.20on.20.60overflow_checks.60.3F)
…thanBrouwer
Add correct suggestion for multi-references for self type in method
Currently the suggestion for this code
```rust
fn main() {}
struct A {
field: i32,
}
impl A {
fn f(&&self) {}
}
```
looks like this, which is incorrect and missleading
```rust
Compiling playground v0.0.1 (/playground)
error: expected one of `!`, `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
--> src/main.rs:8:16
|
8 | fn f(&&self) {}
| ^ expected one of 9 possible tokens
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: explicitly ignore the parameter name
|
8 | fn f(_: &&self) {}
| ++
```
So this fixes it and make more correct suggestions
```rust
error: expected one of `!`, `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
--> /home/gh-Kivooeo/test_/src/main.rs:8:16
|
8 | fn f(&&self) {}
| ^ expected one of 9 possible tokens
|
help: `self` should be `self`, `&self` or `&mut self`, please remove extra references
|
8 - fn f(&&self) {}
8 + fn f(&self) {}
```
Implementation is pretty self-documenting, but if you have suggestions on how to improve this (according to current test, which may be not fully covering all cases, this is works very well) or have some funny edge cases to show, I would appreciate it
r? compiler
[DebugInfo] Fix container types failing to find template args This is a less pervasive (but also less powerful) alternative to rust-lang/rust#144394. This change *only* provides benefits to container types on MSVC. The TL;DR is that nodes that don't populate/aren't discoverable in the PDB for various reasons are given an alternate lookup path that generates the nodes by acquiring the base-type via some gross string manipulation and then asking clang for the node it wants (e.g. `"ref$<i32>"` -> `"i32"` -> `target.FindFirstType("i32").GetPointerType()` -> `i32 *`, which is a valid type for the container to use) The before/afters are the same as in the above PR's `*-msvc` LLDB screenshots. This works as a stopgap while the above PR is evaluated, but I think that PR is still a much better solution.
Rename `downcast_[ref|mut]_unchecked` -> `downcast_unchecked_[ref|mut]` ## Intent Renames `downcast_[ref|mut]_unchecked` to `downcast_unchecked_[ref|mut]` because we want to emphasise that it is the downcast that is unsafe, not the aliasing per: rust-lang/rust#90850 (comment) ## Tracking Issue: rust-lang/rust#90850 (comment) cc `@marc0246`
…Mark-Simulacrum Optimize path components iteration on platforms that don't have prefixes ``` OLD path::bench_path_components_iter 140.20ns/iter +/- 6.08 path::bench_path_file_name 57.62ns/iter +/- 1.62 NEW path::bench_path_components_iter 126.74ns/iter +/- 1.46 path::bench_path_file_name 47.48ns/iter +/- 2.49 ```
Fix rust stdlib build failing for VxWorks Fixes rust-lang/rust#148125. O_NOFOLLOW is not supported on VxWorks. All the other defines/functions have been added to libc(rust-lang/libc@0cd5032)
Modify contributor email entries in .mailmap This adds mailmap entries for duplicates I found in https://thanks.rust-lang.org/rust/all-time/ If I added an entry for you and it is not correct, then please let me know! See the comments at the start of https://github.com/rust-lang/thanks/blob/master/mailmap/src/lib.rs for understanding these entries. After this gets into the repo, the thanks page will be regenerated within a day, and your double entries will be merged. cc ````````@aochagavia```````` cc ````````@fasterthanlime```````` cc ````````@jackh726```````` cc ````````@jakubadamw```````` cc ````````@yaahc```````` cc ````````@jackpot51```````` cc ````````@jonhoo```````` cc ````````@marcoieni```````` cc ````````@onur-ozkan```````` cc ````````@rylev```````` cc ````````@willcrichton```````` cc ````````@yoshuawuyts````````
Remove a remnant of `dyn*` from the parser Follow-up to rust-lang/rust#146664 and rust-lang/rust#143036. `is_explicit_dyn_type` still checked for `TokenKind::Star` which made no sense now that `dyn*` is no more. Removing it doesn't represent a functional change and merely affects diagnostics. That's because the check only dictated whether to interpret `dyn` as the start of a trait object type in Rust 2015 (where this identifier is only a *contextual* keyword). However, we would still fail at the `*` later on as it doesn't start a bound. While at it, I also took the time to clean up in the vicinity.
Rollup of 22 pull requests Successful merges: - rust-lang/rust#128666 (Add `overflow_checks` intrinsic) - rust-lang/rust#146305 (Add correct suggestion for multi-references for self type in method) - rust-lang/rust#147179 ([DebugInfo] Fix container types failing to find template args) - rust-lang/rust#147743 (Show packed field alignment in mir_transform_unaligned_packed_ref) - rust-lang/rust#148079 (Rename `downcast_[ref|mut]_unchecked` -> `downcast_unchecked_[ref|mut]`) - rust-lang/rust#148084 (Optimize path components iteration on platforms that don't have prefixes) - rust-lang/rust#148126 (Fix rust stdlib build failing for VxWorks) - rust-lang/rust#148204 (Modify contributor email entries in .mailmap) - rust-lang/rust#148279 (rustc_builtin_macros: rename bench parameter to avoid collisions with user-defined function names) - rust-lang/rust#148333 (constify result unwrap unchecked) - rust-lang/rust#148539 (Add Allocator proxy impls for Box, Rc, and Arc) - rust-lang/rust#148601 (`invalid_atomic_ordering`: also lint `update` & `try_update`) - rust-lang/rust#148612 (Add note for identifier with attempted hygiene violation) - rust-lang/rust#148613 (Switch hexagon targets to rust-lld) - rust-lang/rust#148619 (Enable std locking functions on AIX) - rust-lang/rust#148644 ([bootstrap] Make `--open` option work with `doc src/tools/error_index_generator`) - rust-lang/rust#148649 (don't completely reset `HeadUsages`) - rust-lang/rust#148673 (Remove a remnant of `dyn*` from the parser) - rust-lang/rust#148675 (Remove eslint-js from npm dependencies) - rust-lang/rust#148680 (Recover `[T: N]` as `[T; N]`) - rust-lang/rust#148688 (Remove unused argument `features` from `eval_config_entry`) - rust-lang/rust#148711 (Use the current lint note id when parsing `cfg!()`) r? `@ghost` `@rustbot` modify labels: rollup
Encode cfg trace, not its early counterpart to fix cross-crate `doc(auto_cfg)` Fixes rust-lang/rust#141301. <details><summary>Rambling about <code>target_feature</code> which I didn't touch here</summary> Regarding rust-lang/rust#141301 (comment) (`#[target_feature(enable = …)]` on inlined cross-crate re-exports), it has the same underlying cause (namely, we neither encode `target_feature` nor `AttributeKind::TargetFeature` in the crate metadata). However, I didn't make that change because I first want to experiment with querying `TyCtxt::codegen_fn_attrs` in rustdoc instead which already works cross-crate (and also use to it for reconstructing `no_mangle`, `export_name`, `link_section` to avoid encoding these attributes unnecessarily (basically reverting rust-lang/rust#144050) as suggested in rust-lang/rust#144004 (comment)). </details> r? GuillaumeGomez
…ieyouxu Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2 Implement the [MCP 932](rust-lang/compiler-team#932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools. Closes rust-lang/rust#148353. Changes: - Update target tier from 3 to 2 in target specification - Update platform documentation - Add CI/CD support for automatic building and distribution via rustup r? jieyouxu cc `@davidtwco` `@Noratrieb`
This updates the rust-version file to 8401398e1f14a24670ee1a3203713dc2f0f8b3a8.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8 Filtered ref: f9e99a8 Upstream diff: rust-lang/rust@73e6c9e...8401398 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
Contributor
|
@folkertdev should I just merge this? Or is there something else to do? |
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.