Add offset_of! macro (RFC 3308)

[beepster4096]

Implements rust-lang/rfcs#3308 (tracking issue #106655) by adding the built in macro core::mem::offset_of. Two of the future possibilities are also implemented:

• Nested field accesses (without array indexing)
• DST support (for Sized fields)

I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it.

cc @thomcc (RFC author)

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occured in rustc_ty_utils::consts.rs

cc @BoxyUwU

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[est31]

What a great PR. It also adds DST support from the get-go which is amazing (I care about that use case a bit xD).

I've seen tests for nested fields, but couldn't find any tests for DSTs. Maybe something like this:

#[test]
#[cfg(not(bootstrap))]
fn offset_in_dst() {
    #[repr(C)]
    struct Foo {
        x: u8,
        y: u16,
        more: [u8],
    }

    const X_OFFSET: usize = offset_of!(Foo, x);
    const Y_OFFSET: usize = offset_of!(Foo, y);

    assert_eq!(X_OFFSET, 0);
    assert_eq!(Y_OFFSET, 2);
}

The implementation also errors nicely in the case of offset_of!(Foo, unsized_field). It would be nice to have that as a test.

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred in src/tools/cargo

cc @ehuss

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

[petrochenkov]

Frontend LGTM, but someone else needs to look at MIR, const eval and codegen.
r? rust-lang/compiler

[cjgillot]

Could you add a few tests?

1. That we give a sensible error on offset_of!(type) and offset_of!(type, ).

2. That the value returned by offset_of! is correct compared to directly taking the field address for a few relevant combinations of fields. Something like this: edit: just saw you put them in coretests.

assert_eq!(addr_of!(base).addr() + offset_of!(base_ty, field), addr_of!(base.field));

3. As you implemented in rustc_const_eval, a mir-opt test that ConstProp replaces with the correct value when the type is sufficiently known. One test on a non-generic type, one on a partially generic with known layout, and one on a partially generic with unknown layout.

[WaffleLapkin]

Thank you for the work you've put into this, @drmeepster! I think this is ready to be merged now, congrats!

[WaffleLapkin]

@bors r+

[bors]

📌 Commit 99abe44 has been approved by WaffleLapkin

It is now in the queue for this repository.

[bors]

⌛ Testing commit 99abe44 with merge 80a2ec4...

[bors]

☀️ Test successful - checks-actions
Approved by: WaffleLapkin
Pushing 80a2ec4 to master...

[rust-timer]

Finished benchmarking commit (80a2ec4): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.7%	[1.7%, 1.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.6%	[-4.8%, -2.7%]	3
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.