Open
Conversation
Collaborator
|
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred to the CTFE machinery Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri HIR ty lowering was modified cc @fmease |
rustbot
added
S-waiting-on-review
Collaborator
|
|
This comment has been minimized.
This comment has been minimized.
BennoLossin
force-pushed
the
field-projections-lang-item
branch
from
fe3fa8b to
f5f42d1
Compare
Collaborator
|
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
rustbot
added
A-rustdoc-json
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
oli-obk
added
the
I-types-nominated
BennoLossin
force-pushed
the
field-projections-lang-item
branch
from
72f9813 to
2c83a72
Compare
This comment has been minimized.
This comment has been minimized.
BennoLossin
force-pushed
the
field-projections-lang-item
branch
from
2c83a72 to
edbf7d1
Compare
This comment has been minimized.
This comment has been minimized.
BennoLossin
force-pushed
the
field-projections-lang-item
branch
from
edbf7d1 to
a94a2f8
Compare
oli-obk
requested changes
Feb 20, 2026
rustbot
added
S-waiting-on-author
Collaborator
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
Contributor
Author
|
I had to move the indexes, since @rustbot ready |
rustbot
added
S-waiting-on-review
Contributor
|
Yep, that looks correct. Please squash the new commits into the appropriate main ones. Then I'll approve it |
BennoLossin
force-pushed
the
field-projections-lang-item
branch
from
503326e to
e7bae32
Compare
55 tasks
Contributor
|
If we do go with this design with a new |
theemathas
reviewed
Feb 21, 2026
library/core/src/field.rs
Outdated
| #[unstable(feature = "field_projections", issue = "145383")] | ||
| #[rustc_deny_explicit_impl] | ||
| #[rustc_dyn_incompatible_trait] | ||
| pub unsafe trait Field: Send + Sync + Copy + Sized { |
Contributor
There was a problem hiding this comment.
Since this Field trait requires Send and Sync, I assume that the FieldRepresentingType type needs to have unconditional Send and Sync impls, as opposed to inheriting the auto traits via the PhantomData field.
Contributor
|
This code prints 4 with this PR, ignoring the possibility that the DST field might need extra padding for alignment: #![feature(field_projections)]
#![expect(incomplete_features, dead_code)]
use std::field::{Field, field_of};
struct Thing(i32, dyn Send + Sync);
fn main() {
let x = <field_of!(Thing, 1) as Field>::OFFSET;
println!("{x}");
}In contrast, #![expect(dead_code)]
use std::mem::offset_of;
struct Thing(i32, dyn Send + Sync);
fn main() {
let x = offset_of!(Thing, 1);
println!("{x}");
} |
Contributor
|
The following code ICEs with this PR, due to the FRT implementing the #![feature(field_projections)]
#![expect(incomplete_features, dead_code)]
use std::field::{Field, field_of};
struct Thing(dyn Send + Sync);
fn main() {
foo::<field_of!(Thing, 0)>();
}
fn foo<F: Field>() {
let _ = Box::<<F as Field>::Type>::new_uninit();
}Error output |
theemathas
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
Contributor
|
Field-representing types can cause privacy violations. See the following code: dep/src/lib.rs #![feature(field_projections)]
#![expect(incomplete_features)]
use std::field::field_of;
struct Inner;
pub struct Outer(Inner);
pub type MyField = field_of!(Outer, 0);
pub trait GetUnreachable {
type Assoc;
}
mod m {
pub struct Unreachable;
impl Unreachable {
#[expect(dead_code)]
pub fn method() {}
}
impl crate::GetUnreachable for crate::Inner {
type Assoc = Unreachable;
}
}src/main.rs #![feature(field_projections)]
#![expect(incomplete_features)]
use std::field::Field;
use dep::{GetUnreachable, MyField};
fn main() {
<MyField as Access>::AccessAssoc::method();
}
trait Access {
type AccessAssoc;
}
impl<T: Field<Type: GetUnreachable>> Access for T {
type AccessAssoc = <T::Type as GetUnreachable>::Assoc;
}Error output when compiling this code with this PR: See also #151284 I'm guessing that |
Contributor
That, or reachability needs to process FRTs similar to projections and look at more than just the types in the generic args. That's an annoying complication though, so adding the field type directly to the frt is the least invasive scheme |
Contributor
|
Actually... there's another side effect of adding a second type parameter for dep/src/lib.rs: pub struct Outer<T>(pub T);
pub trait Trait {}src/lib.rs: #![feature(field_projections)]
#![expect(incomplete_features)]
use std::field::field_of;
use dep::{Outer, Trait};
struct Inner;
impl Trait for field_of!(Outer<Inner>, 0) {}This code currently doesn't compile with the PR, producing the following error: However, I believe that it will compile if This seems undesirable, since now |
Contributor
|
We can land this PR as is and do a follow-up for the privacy issue as there may be multiple ways to go about it and none of them really require major divergence from this PR So to land:
|
Contributor
|
I think the Send/Sync issue and the DST issue seem not too hard to fix, so maybe those could also be fixed in this PR before merging if that's not too much trouble? |
fmease
reviewed
Feb 23, 2026
BennoLossin
force-pushed
the
field-projections-lang-item
branch
from
e7bae32 to
8c1da56
Compare
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Contributor
Author
I think so too. I fixed the send/sync thing as well as @fmease's suggestions now. I'll take a look at the DST fixes tomorrow. Thanks a lot for taking a look @theemathas! |
13 tasks
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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
7 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.
View all comments
Note
This is a rewrite of #146307 by using a lang item instead of a custom
TyKind. We still need ahir::TyKind::FieldOfvariant, 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 between the two PRs
Add Field Representing Types (FRTs)
This PR implements the first step of the field projection lang experiment (Tracking Issue: #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
Fieldtrait 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 theFieldtrait.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
coreinstead of creating my own using the hash of the name of the field. See the Rust-for-Linux/field-projectionlang-experimentbranch.API added to
core::fieldAlong with a perma-unstable type that the compiler uses in the expansion of the macro:
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 aPinnableFieldtrait 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. TheFieldtraits should be implemented by the compiler & populated with correct information (unsafecode needs to be able to rely on them being correct).TODOs
There are some
FIXME(FRTs)scattered around the code:field_of!can be improvedtests/ui/field_representing_types/nonexistent.rstests/ui/field_representing_types/non-struct.rstests/ui/field_representing_types/offset.rstests/ui/field_representing_types/not-field-if-packed.rstests/ui/field_representing_types/invalid.rscompiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rsr? @oli-obk