Rollup of 8 pull requests#153315
Closed
JonathanBrouwer wants to merge 20 commits intorust-lang:mainfrom
Closed
Conversation
The behavior in the test case matches rustc's:
test-dingus % ls
main.rs
test-dingus % mkdir foobar
test-dingus % rustc --emit=dep-info main.rs --out-dir=foobar
test-dingus % ls
foobar main.rs
test-dingus % ls foobar
main.d
test-dingus % rustc --emit=dep-info=testfile.d main.rs --out-dir=foobar
test-dingus % ls
foobar main.rs testfile.d
test-dingus % ls foobar
main.d
This refactor will make an upcoming change smaller, and also adds exhaustive matching.
This adds a variant `NoneWithError` to AST and HIR representations of the “rest” or “tail”, which is currently always treated identically to the `None` variant.
This prevents spurious errors when a field is intended to be present
but a preceding syntax error caused it not to be parsed. For example,
StructName { foo: 1 bar: 2 }
will not successfully parse a field `bar`, and we will report the syntax
error but not the missing field.
The HermitCore name was dropped a while ago, the project is now simply called "Hermit".
The HermitCore name was dropped a while ago, the project is now simply called "Hermit".
* Adjust macro description * Copy Cargo's release notes for more details * Apply suggestions from code review Co-authored-by: 许杰友 Jieyou Xu (Joe) <39484203+jieyouxu@users.noreply.github.com> Co-authored-by: alexey semenyuk <alexsemenyuk88@gmail.com> Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
…agation, r=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#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
prefer actual ABI-controling fields over target.abi when making ABI decisions We don't actually check that `abi` is consistent with the fields that control the ABI, e.g. one could set `llvm_abiname` to "ilp32e" on a riscv target without setting a matching `abi`. So, if we need to make actual decisions, better to use the source of truth we forward to LLVM than the informational string we forward to the user. This is a breaking change for aarch64 JSON target specs: setting `abi` to "softfloat" is no longer enough; one has to also set `rustc_abi` to "softfloat". That is consistent with riscv and arm32, but it's still surprising. Cc @Darksonn in case this affects the Linux kernel. Also see rust-lang#153035 which does something similar for PowerPC, and [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/575095372). Happy to delay this PR if someone has a better idea. Cc @folkertdev @workingjubilee
…ebank Don’t report missing fields in struct exprs with syntax errors. @Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently. Specifically, if the user writes a struct literal with a syntax error, such as ```rust StructName { foo: 1 bar: 2 } ``` the compiler will no longer report that the field `bar` is missing in addition to the syntax error. This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`. **Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.
… r=Kivooeo Migrate 11 tests from tests/ui/issues to specific directories Moved 11 regression tests from `tests/ui/issues` to their relevant subdirectories (`imports`, `pattern`, `lint`, and `typeck`). * Added standard issue tracking comments at the top of each file. * Relocated associated `aux-build` files. * Ran `./x.py test --bless` successfully.
rustdoc: make `--emit` and `--out-dir` mimic rustc
The behavior in the test case matches rustc's:
test-dingus % ls
main.rs
test-dingus % mkdir foobar
test-dingus % rustc --emit=dep-info main.rs --out-dir=foobar
test-dingus % ls
foobar main.rs
test-dingus % ls foobar
main.d
test-dingus % rustc --emit=dep-info=testfile.d main.rs --out-dir=foobar
test-dingus % ls
foobar main.rs testfile.d
test-dingus % ls foobar
main.d
CC rust-lang#146220 (comment)
…ostic, r=Kivooeo Remove unhelpful hint from trivial bound errors The `= help: see issue rust-lang#48214` hint on trivial bound errors isn't useful, most users hitting these errors aren't trying to use the `trivial_bounds` feature. The `disabled_nightly_features` call already handles suggesting the feature gate on nightly. Closes rust-lang#152872
Add release notes for 1.94.0 Replaces rust-lang#151650. r? cuviper
Update the name of the Hermit operating system The HermitCore name was dropped a while ago, the project is now simply called "Hermit". See for example [the website](https://hermit-os.org/). cc @stlankes @mkroening
rustbot
added
A-LLVM
rustbot
added
the
T-rustfmt
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
Contributor
Author
|
Trying commonly failed jobs |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 2, 2026
Rollup of 8 pull requests try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 3, 2026
…uwer Rollup of 8 pull requests Successful merges: - #151864 (Implement AST -> HIR generics propagation in delegation) - #152941 (prefer actual ABI-controling fields over target.abi when making ABI decisions) - #153227 (Don’t report missing fields in struct exprs with syntax errors.) - #152966 (Migrate 11 tests from tests/ui/issues to specific directories) - #153003 (rustdoc: make `--emit` and `--out-dir` mimic rustc) - #153034 (Remove unhelpful hint from trivial bound errors) - #153221 (Add release notes for 1.94.0) - #153297 (Update the name of the Hermit operating system)
rust-bors
bot
added
S-waiting-on-review
Contributor
|
💔 Test for 56c4dcd failed: CI. Failed job:
|
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
bot
added
S-waiting-on-author
Contributor
|
💔 Test for a1940e9 failed: CI. Failed job:
|
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rustbot
removed
the
S-waiting-on-author
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
11 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.
Successful merges:
--emitand--out-dirmimic rustc #153003 (rustdoc: make--emitand--out-dirmimic rustc)r? @ghost
Create a similar rollup