Merged
Conversation
loongarch: Sync SIMD intrinsics with C
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@1396514 Filtered ref: rust-lang/stdarch@b1e0e47 Upstream diff: rust-lang/rust@db3e99b...1396514 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
use `intrinsics::simd` for `vmull_*`
…JonathanBrouwer Re-add `#[inline]` to `Eq::assert_fields_are_eq` Fixes a compile-time regression in rust-lang/rust#149978: non-inline methods are generally codegen'd while inline methods are deferred (and this function should never be called, so deferring is the right choice). r? JonathanBrouwer CC @cyrgani
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.
…petrochenkov Implement AST -> HIR generics propagation in delegation This PR adds support for generics propagation during AST -> HIR lowering and is a part of rust-lang/rust#118212. # High-level design overview ## Motivation The task is to generate generics for delegations (i.e. in this context we assume a function that is created for `reuse` statements) during AST -> HIR lowering. Then we want to propagate those generated params to generated method call (or default call) in delegation. This will help to solve issues like the following: ```rust mod to_reuse { pub fn consts<const N: i32>() -> i32 { N } } reuse to_reuse::consts; //~^ ERROR type annotations needed // DESUGARED CURRENT: #[attr = Inline(Hint)] fn consts() -> _ { to_reuse::consts() } // DESUGARED DESIRED: #[attr = Inline(Hint)] fn consts<const N: i32>() -> _ { to_reuse::consts::<N>() } ``` Moreover, user can specify generic args in `reuse`, we need to propagate them (works now) and inherit signature with substituted generic args: ```rust mod to_reuse { pub fn foo<T>(t: T) -> i32 { 0 } } reuse to_reuse::foo::<i32>; //~^ ERROR mismatched types fn main() { foo(123); } error[E0308]: mismatched types --> src/main.rs:24:17 | 19 | pub fn foo<T>(t: T) -> i32 { | - found this type parameter ... 24 | reuse to_reuse::foo::<i32>; | ^^^ | | | expected `i32`, found type parameter `T` | arguments to this function are incorrect | = note: expected type `i32` found type parameter `T` ``` In this case we want the delegation to have signature that have one `i32` parameter (not `T` parameter). Considering all other cases, for now we want to preserve existing behavior, which was almost fully done (at this stage there are changes in behavior of delegations with placeholders and late-bound lifetimes). ## Main approach overview The main approach is as follows: - We determine generic params of delegee parent (now only trait can act as a parent as delegation to inherent impls is not yet supported) and delegee function, - Based on presence of user-specified args in `reuse` statement (i.e. `reuse Trait::<'static, i32, 123>::foo::<String>`) we either generate delegee generic params or not. If not, then we should include user-specified generic args into the signature of delegation, - The general order of generic params generation is as following: `[DELEGEE PARENT LIFETIMES, DELEGEE LIFETIMES, DELEGEE PARENT TYPES AND CONSTS, DELEGEE TYPES AND CONSTS]`, - There are two possible generic params orderings (they differ only in a position of `Self` generic param): - When Self is after lifetimes, this happens only in free to trait delegation scenario, as we need to generate implicit Self param of the delegee trait, - When Self is in the beginning and we should not generate Self param, this is basically all other cases if there is an implicit Self generic param in delegation parent. - Considering propagation, we do not propagate lifetimes for child, as at AST -> HIR lowering stage we can not know whether the lifetime is late-bound or early bound, so for now we do not propagate them at all. There is one more hack with child lifetimes, for the same reason we create predicates of kind `'a: 'a` in order to preserve all lifetimes in HIR, so for now we can generate more lifetimes params then needed. This will be partially fixed in one of next pull requests. ## Implementation details - We obtain AST generics either from AST of a current crate if delegee is local or from external crate through `generics_of` of `tcx`. Next, as we want to generate new generic params we generate new node ids for them, remove default types and then invoke already existent routine for lowering AST generic params into HIR, - If there are user-specified args in either parent or child parts of the path, we save HIR ids of those segments and pass them to `hir_analysis` part, where user-specified args are obtained, then lowered through existing API and then used during signature and predicates inheritance, - If there are no user-specified args then we propagate generic args that correspond to generic params during generation of delegation, - During signature inheritance we know whether parent or child generic args were specified by the user, if so, we should merge them with generic params (i.e. cases when parent args are specified and child args are not: `reuse Trait::<String>::foo`), next we use those generic args and mapping for delegee parent and child generic params into those args in order to fold delegee signature and delegee predicates. ## Tests New tests were developed and can be found in `ast-hir-engine` folder, those tests cover all cases of delegation with different number of lifetimes, types, consts in generic params and different user-specified args cases (parent and child, parent/child only, none). ## Edge cases There are some edge cases worth mentioning. ### Free to trait delegation. Consider this example: ```rust trait Trait<'a, T, const N: usize> { fn foo<'x: 'x, A, B>(&self) {} } reuse Trait::foo; ``` As we are reusing from trait and delegee has `&self` param it means that delegation must have `Self` generic param: ```rust fn foo<'a, 'x, Self, T, const N: usize, A, B>(self) {} ``` We inherit predicates from Self implicit generic param in `Trait`, thus we can pass to delegation anything that implements this trait. Now, consider the case when user explicitly specifies parent generic args. ```rust reuse Trait::<'static, String, 1>::foo; ``` In this case we do not need to generate parent generic params, but we still need to generate `Self` in delegation (`DelegationGenerics::SelfAndUserSpecified` variant): ```rust fn foo<'x, Self, A, B>(self) {} ``` User-specified generic arguments should be used to replace parent generic params in delegation, so if we had param of type `T` in `foo`, during signature inheritance we should replace it with user-specified `String` type. ### impl trait delegation When we delegate from impl trait to something, we want the delegation to have signature that matches signature in trait. For this reason we already resolve delegation not to the actual delegee but to the trait method in order to inherit its signature. That is why when processing user-specified args when the caller kind is `impl trait` (`FnKind::AssocTraitImpl`), we discard parent user-specified args and replace them with those that are specified in trait header. In future we will also discard `child_args` but we need proper error handling for this case, so it will be addressed in one of future pull requests that are approximately specified in "Nearest future work" section. ## Nearest future work (approximate future pull requests): - Late-bound lifetimes - `impl Trait` params in functions - Proper propagation of parent generics when generating method call - ~Fix diagnostics duplication during lowering of user-specified types~ - Support for recursive delegations - Self types support `reuse <u8 as Trait<_>>::foo as generic_arguments2` - Decide what to do with infer args `reuse Trait::<_, _>::foo::<_>` - Proper error handling when there is a mismatch between actual and expected args (impl trait case) r? @petrochenkov
…rtdev stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@d4a226d. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…gau,jhpratt
Parse `impl` restrictions
This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.
r? @jhpratt
Comments and docs: add missing periods to "ie." "i.e." is short for the Latin "id est" and thus both letters should be followed by periods.
Make `rustc_with_all_queries!` pass query modifiers as named values
This PR is a bold overhaul of how the proc-macro in `rustc_macros::query` passes query modifiers to the callback macros in `rustc_middle` and `rustc_query_impl`.
The existing approach passes modifiers as a list that looks like `[(arena_cache), (no_hash)]`. That style requires a family of helper macros (`if_arena_cache!`, `if_no_hash!`) to check for modifiers when consuming the query list.
This PR changes the proc-macro to instead pass modifiers like this:
```text
{
anon: false,
arena_cache: true,
cache_on_disk: false,
...
}
```
This style allows each of the callback macros to deconstruct the modifier list in a relatively straightforward way, by binding the true/false literals to variables like `$arena_cache:literal`.
One of the big advantages of this style is that we can write things like `#[cfg($arena_cache)]` and `#[cfg(not($arena_cache))]` to select blocks of code, eliminating the need for the `if_arena_cache!` family of helper macros.
In follow-up PRs, we can also try to take advantage of the new modifier style to pass richer information for some modifiers, such as `desc` or `cache_on_disk_if`. That could potentially make it more reasonable to get rid of the `_description_fns` and `_cache_on_disk_if_fns` modules, as proposed in rust-lang/rust#153065.
r? nnethercote
…uwer Rollup of 6 pull requests Successful merges: - rust-lang/rust#153336 (stdarch subtree update) - rust-lang/rust#152943 (Parse `impl` restrictions) - rust-lang/rust#153184 (Replace CodegenResults with CompiledModules) - rust-lang/rust#153285 (Update call-llvm-intrinsics test for Rust 1.94.0 IR) - rust-lang/rust#153319 (Comments and docs: add missing periods to "ie.") - rust-lang/rust#153326 (Make `rustc_with_all_queries!` pass query modifiers as named values)
…nathanBrouwer Lint unused features *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152164)* Fixes rust-lang/rust#44232 Fixes rust-lang/rust#151752 --- This PR records used features through query side effect, then reports unsued features finally.
Refactor WriteBackendMethods a bit
Update path separators to be available in const context Tracking issue: rust-lang/rust#153106 This makes platform-dependent secondary path separators available in const context (ie. at compile time). The platform definitions have also been consolidated behind a common macro to prevent transcription errors, whereas previously they were defined 3-4 times per platform. ### Questions I've manually verified that this compiles against each platform. It seems like no unit tests should be required for this change; is that correct?
Add `#[must_use]` attribute to `HashMap` and `HashSet` constructors - `new_in` - `with_capacity_and_hasher` - `with_capacity_and_hasher_in` - `with_hasher` - `with_hasher_in` See also: rust-lang/rust#89692
…oli-obk Abort after `representability` errors Doing so results in better error messages and makes the code a bit simpler. Details in individual commits. r? @oli-obk
Remove `cycle_fatal` query modifier This removes the `cycle_fatal` query modifier as it has no effect on its current users. The default `CycleErrorHandling::Error` mode does the same as `cycle_fatal` when the default impl of `FromCycleError` is used. The return types of queries using `cycle_fatal` however have no specialized `FromCycleError` impl.
Tweak some of our internal `#[rustc_*]` TEST attributes
I think I might be the one who's used the internal TEST attrs `#[rustc_{dump_predicates,object_lifetime_default,outlives,variance}]` the most in recent times, I might even be the only one. As such I've noticed some recent-ish issues that haven't been fixed so far and which keep bothering me. Moreover I have a longstanding urge to rename several of these attributes which I couldn't contain anymore.
[`#[rustc_*]` TEST attributes](https://rustc-dev-guide.rust-lang.org/compiler-debugging.html#rustc_-test-attributes) are internal attributes that basically allow you to dump the output of specific queries for use in UI tests or for debugging purposes.
1. When some of these attributes were ported over to the new parsing API, their targets were unnecessarily restricted. I've kept encountering these incorrect "attribute cannot be used" errors all the while HIR analysis happily & correctly dumped the requested data below it. I've now relaxed their targets.
2. Since we now have target checking for the internal attributes I figured that it's unhelpful if we still intentionally crashed on invalid targets, so I've got rid of that.
3. I've always been annoyed that most of these (very old) attributes don't contain the word `dump` in their name (rendering their purpose non-obvious) and that some of their names diverge quite a bit from the corresponding query name. I've now rectified that. The new names take longer to type but it's still absolutely acceptable imo.
---
I haven't renamed all of the TEST attributes to follow the `rustc_dump_` scheme since that's quite tedious. If it's okay with you I'd like to postpone that (e.g., `rustc_{def_path,hidden_type…,layout,regions,symbol_name}`).
I've noticed that the parsers for TEST attrs are spread across `rustc_dump.rs`, `rustc_internal.rs` & `test_attrs.rs` which is a bit confusing. Since the new names are prefixed with `rustc_dump_` I've moved their parsers into `rustc_dump.rs` but of course they are still TEST attrs. IIRC, `test_attrs.rs` also contains non-`rustc_`-TEST attrs, so we can't just merge these two files. I guess that'll sort itself out in the future when I tackle the other internal TEST attrs.
r\? Jana || Jonathan
use `minicore` in some `run-make` tests r? jieyouxu This manually builds `minicore` in two more `rmake` tests that rolled their own before, and adds a helper for the path of the minicore source. I tried adding a true minicore helper in `run_make_support` but unfortunately the minicore build needs to inherit some (but probably not all) arguments of the final rustc invocation (notably `target` and `target_cpu`), so a one-size-fits-all helper doesn't really work as far as I can see. For now with 3 uses this is probably fine, but there are probably other `run-make` tests that could use `minicore` but didn't document/simulate that. follow-up to discussion in rust-lang/rust#153153.
Migrationg of `LintDiagnostic` - part 7 Part of rust-lang/rust#153099. This PR removes the `LintDiagnostic` trait and proc-macro. \o/ r? @JonathanBrouwer
Remove a ping for myself To improve the SNR for my notifs. r? ghost
Rename translation -> formatting Because there is no translation happening anymore r? @Kivooeo
…tfe, r=RalfJung Do not deduce parameter attributes during CTFE *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/151842)* Ever since rust-lang/rust#103172, `fn_abi_of_instance` might look at a function's body to deduce certain codegen optimization attributes for its indirectly-passed parameters beyond what can be determined purely from its signature (namely today `ArgAttribute::ReadOnly` and `ArgAttribute::CapturesNone`). Since rust-lang/rust#130201, looking at a function's body in this way entails generating, for any coroutine-closures, additional by-move MIR bodies (which aren't represented in the HIR)—but this requires knowing the types of their context and consequently cycles can ensue if such bodies are generated before typeck is complete (such as during CTFE). Since they have no bearing on the evaluation result, this patch breaks a subquery out from `fn_abi_of_instance`, `fn_abi_of_instance_no_deduced_attrs`, which returns the ABI before such parameter attributes are deduced; and that new subquery is used in CTFE instead (however, since parameter attributes are only deduced in optimized builds, as a performance optimization we avoid calling the original query unless we are performing such a build). Fixes rust-lang/rust#151748 Fixes rust-lang/rust#152497
…uwer Rollup of 12 pull requests Successful merges: - rust-lang/rust#153402 (miri subtree update) - rust-lang/rust#152164 (Lint unused features) - rust-lang/rust#152801 (Refactor WriteBackendMethods a bit) - rust-lang/rust#153196 (Update path separators to be available in const context) - rust-lang/rust#153204 (Add `#[must_use]` attribute to `HashMap` and `HashSet` constructors) - rust-lang/rust#153317 (Abort after `representability` errors) - rust-lang/rust#153276 (Remove `cycle_fatal` query modifier) - rust-lang/rust#153300 (Tweak some of our internal `#[rustc_*]` TEST attributes) - rust-lang/rust#153396 (use `minicore` in some `run-make` tests) - rust-lang/rust#153401 (Migrationg of `LintDiagnostic` - part 7) - rust-lang/rust#153406 (Remove a ping for myself) - rust-lang/rust#153414 (Rename translation -> formatting)
This updates the rust-version file to f8704be04fe1150527fc2cf21dd44327f0fe87fb.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@f8704be Filtered ref: 5ecd3ed Upstream diff: rust-lang/rust@e7d90c6...f8704be This merge was created using https://github.com/rust-lang/josh-sync.
rustbot
added
the
S-waiting-on-review
lnicola
approved these changes
Mar 5, 2026
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
8 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.