Rollup of 9 pull requests#153208
Closed
JonathanBrouwer wants to merge 32 commits intorust-lang:mainfrom
Closed
Conversation
…l be forced to take them into account when inlining
Improve cross-crate trait impl param mismatch suggestions resolve: rust-lang#106999
…-item, r=oli-obk add field representing types *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152730)* > [!NOTE] > This is a rewrite of rust-lang#146307 by using a lang item instead of a custom `TyKind`. We still need a `hir::TyKind::FieldOf` variant, because resolving the field name cannot be done before HIR construction. The advantage of doing it this way is that we don't need to make any changes to types after HIR (including symbol mangling). At the very beginning of this feature implementation, I tried to do it using a lang item, but then quickly abandoned the approach, because at that time I was still intending to support nested fields. Here is a [range-diff](https://triagebot.infra.rust-lang.org/gh-range-diff/rust-lang/rust/605f49b27444a738ea4032cb77e3bdc4eb811bab..d15f5052095b3549111854a2555dd7026b0a729e/605f49b27444a738ea4032cb77e3bdc4eb811bab..f5f42d1e03495dbaa23671c46b15fccddeb3492f) between the two PRs --- # Add Field Representing Types (FRTs) This PR implements the first step of the field projection lang experiment (Tracking Issue: rust-lang#145383). Field representing types (FRTs) are a new kind of type. They can be named through the use of the `field_of!` macro with the first argument being the type and the second the name of the field (or variant and field in the case of an enum). No nested fields are supported. FRTs natively implement the `Field` trait that's also added in this PR. It exposes information about the field such as the type of the field, the type of the base (i.e. the type that contains the field) and the offset within that base type. Only fields of non-packed structs are supported, fields of enums an unions have unique types for each field, but those do not implement the `Field` trait. This PR was created in collaboration with @dingxiangfei2009, it wouldn't have been possible without him, so huge thanks for mentoring me! I updated my library solution for field projections to use the FRTs from `core` instead of creating my own using the hash of the name of the field. See the [Rust-for-Linux/field-projection `lang-experiment` branch](https://github.com/Rust-for-Linux/field-projection/tree/lang-experiment). ## API added to `core::field` ```rust pub unsafe trait Field { type Base; type Type; const OFFSET: usize; } pub macro field_of($Container:ty, $($fields:expr)+ $(,)?); ``` Along with a perma-unstable type that the compiler uses in the expansion of the macro: ```rust #[unstable(feature = "field_representing_type_raw", issue = "none")] pub struct FieldRepresentingType<T: ?Sized, const VARIANT: u32, const FIELD: u32> { _phantom: PhantomData<T>, } ``` ## Explanation of Field Representing Types (FRTs) FRTs are used for compile-time & trait-level reflection for fields of structs & tuples. Each struct & tuple has a unique compiler-generated type nameable through the `field_of!` macro. This type natively contains information about the field such as the outermost container, type of the field and its offset. Users may implement additional traits on these types in order to record custom information (for example a crate may define a [`PinnableField` trait](https://github.com/Rust-for-Linux/field-projection/blob/lang-experiment/src/marker.rs#L9-L23) that records whether the field is structurally pinned). They are the foundation of field projections, a general operation that's generic over the fields of a struct. This genericism needs to be expressible in the trait system. FRTs make this possible, since an operation generic over fields can just be a function with a generic parameter `F: Field`. > [!NOTE] > The approach of field projections has changed considerably since this PR was opened. In the end we might not need FRTs, so this API is highly experimental. FRTs should act as though they were defined as `struct MyStruct_my_field<StructGenerics>;` next to the struct. So it should be local to the crate defining the struct so that one can implement any trait for the FRT from that crate. The `Field` traits should be implemented by the compiler & populated with correct information (`unsafe` code needs to be able to rely on them being correct). ## TODOs There are some `FIXME(FRTs)` scattered around the code: - Diagnostics for `field_of!` can be improved - `tests/ui/field_representing_types/nonexistent.rs` - `tests/ui/field_representing_types/non-struct.rs` - `tests/ui/field_representing_types/offset.rs` - `tests/ui/field_representing_types/not-field-if-packed.rs` - `tests/ui/field_representing_types/invalid.rs` - Simple type alias already seem to work, but might need some extra work in `compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs` r? @oli-obk
… r=lolbinarycat Correctly handle `#[doc(alias = "...")]` attribute on inlined reexports Fixes rust-lang#152939. During the doc attributing migration to the new API, this information got lost. At least now we have a test for it. :) r? @lolbinarycat
Normalize capture place `ty`s to prevent ICE Fixes rust-lang#151579 Fixes rust-lang#120811 r? @lcnr
…alueFormat-aarch64-gnu-debug, r=marcoieni Fix LegacyKeyValueFormat report from docker build: aarch64-gnu-debug Part of rust-lang#152305 r? @marcoieni
…r=lcnr Fix comment about placeholders r? @lcnr When this was introduced, briefly returned an `Option`, which is what the comment refers to. rust-lang@a9f1e1c#diff-8d11697c196da9f44774488ae0bf353283e5c6466a6dd570d7818431b73d4a44R511 Before that this code would just panic, and in the commit right after fixing review comments it does so again: rust-lang@cf001dc#diff-8d11697c196da9f44774488ae0bf353283e5c6466a6dd570d7818431b73d4a44R560 That comment has been copied around for 5 years now despite not reflecting the behavior hehe Second commit has some general typos I found
…ng, r=petrochenkov Fix ICE when macro-expanded extern crate shadows std Fixes rust-lang#152895 This PR fixes an ICE that occurs when a macro-expanded `extern crate` shadows a prelude name, which leaves the resolver in an inconsistent state due to `issue_145575_hack`. I disabled the assertion when the `issue_145575_hack` flag is enabled. The fix is applied in two locations to cover both cases (whether `is_error_from_last_segment` is true or false). This approach was inspired by the context and fix discussed in rust-lang#151213.
… r=jdonszelmann Don't allow subdiagnostic to use variables from their parent Tangentially related to rust-lang#151366 This is PR 1/2 for structured diagnostics, will do the unstructured ones next. After the second PR I will be able to remove some code that should compensate for this PR being positive. Regardless of this PR having a positive diff, I feel that subdiagnostics being able to use variables from their parent is very confusing, so this is for the better,. r? @jdonszelmann
…r=Kivooeo Remove redundant clone Don't clone file content just for utf8 checks.
rustbot
added
A-CI
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
Contributor
Author
|
Trying commonly failed jobs |
Contributor
|
⌛ Trying commit 558e1d7 with merge 9f7ec44… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/22516077833 |
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 28, 2026
Rollup of 9 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
Contributor
Author
Contributor
|
Try build cancelled. Cancelled workflows: |
Contributor
|
📋 Only unclosed PRs can be unapproved. |
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
10 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:
#[doc(alias = "...")]attribute on inlined reexports #153136 (Correctly handle#[doc(alias = "...")]attribute on inlined reexports)tys to prevent ICE #152165 (Normalize capture placetys to prevent ICE)r? @ghost
Create a similar rollup