add field representing types

[BennoLossin]

View all comments

Note

This is a rewrite of #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 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 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.

API added to core::field

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:

#[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 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

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

HIR ty lowering was modified

cc @fmease

[rustbot]

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[theemathas]

The tracking issue should probably be edited to mention the visibility problem.

[oli-obk]

@bors r+

[rust-bors]

📌 Commit 7b42859 has been approved by oli-obk

It is now in the queue for this repository.

[BennoLossin]

@theemathas done & thanks for pinging about that again!

[theemathas]

The following code causes the compiler to stack overflow with this PR:

#![feature(field_projections)]
#![expect(incomplete_features)]

use std::field::{Field, field_of};

pub struct Weird<T>(<field_of!(Weird<Option<T>>, 0) as Field>::Type);

   Compiling foo v0.1.0 (C:\Users\theem\Documents\foo)

thread 'rustc' (14528) has overflowed its stack
error: could not compile `foo` (lib)

Caused by:
  process didn't exit successfully: `C:\Users\theem\.rustup\toolchains\stage1\bin\rustc.exe --crate-name foo --edition=2024 src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=66 --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --check-cfg cfg(docsrs,test) --check-cfg "cfg(feature, values())" -C metadata=34422770a8dd516b -C extra-filename=-b905b216856408c3 --out-dir C:\Users\theem\Documents\foo\target\debug\deps -C incremental=C:\Users\theem\Documents\foo\target\debug\incremental -L dependency=C:\Users\theem\Documents\foo\target\debug\deps` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)

[fmease]

I would say we probably shouldn't block this PR on it (unless it's exposing a fundamental flaw) but open a GH issue once this PR is merged.

[ytmimi]

@BennoLossin any chance you can open up a follow up PR to add a formatting test case for this like I asked in #152730 (comment)?

The tests should be pretty simple. Check out these other examples that use builtin syntax:

• src/tools/rustfmt/tests/target/issue_6159.rs
• src/tools/rustfmt/tests/target/issue-6105.rs
• src/tools/rustfmt/tests/target/issue-5885.rs

All you'd need to do is add a test file to src/tools/rustfmt/tests/target with an example of how this is meant to be formatted in practice using the builtin syntax.

[BennoLossin]

Oh sure, sorry about forgetting that, filed a PR: #153229

[theemathas]

I've filed the circularly-defined struct as #153256. For some reason, it now causes the compiler to hang in my testing, instead of the previously-observed stack overflow.

[oli-obk]

For some reason, it now causes the compiler to hang in my testing, instead of the previously-observed stack overflow.

Local builds are less optimized and may successfully hit existing stack growing instructions before blowing up. The root issue of an infinite recursion is the same.