Support enum variants in offset_of!

[GKFX]

This MR implements support for navigating through enum variants in offset_of!, placing the enum variant name in the second argument to offset_of!. The RFC placed it in the first argument, but I think it interacts better with nested field access in the second, as you can then write things like

offset_of!(Type, field.Variant.field)

Alternatively, a syntactic distinction could be made between variants and fields (e.g. field::Variant.field) but I'm not convinced this would be helpful.

RFC 3308 # Enum Support
Tracking Issue #106655.

[rustbot]

r? @wesleywiser

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

[rustbot]

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

This PR changes MIR

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

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

This PR changes Stable MIR

cc @oli-obk, @celinval, @spastorino

[GKFX]

cc @thomcc as the RFC author.

[bjorn3]

For MIR we are using (val as Variant).field as syntax for accessing variant fields. I don't think it works well with the offset_of!() syntax though.

[bors]

☔ The latest upstream changes (presumably #114614) made this pull request unmergeable. Please resolve the merge conflicts.

[llogiq]

So once this is merged, the syntax to get the offset of the Some value from an Option would then be offset_of!(Option, Some.0), right? Edit: Yes, this was even in the error description example. Having some docs for this on the offset_of! macro itself would also be nice.

Also I dislike the rule of "last part must be field". I think we should rather specify it as "field must follow enum variant". Otherwise people may try SomeType.SomeVariant.InnerVariant.field and make it really unclear once SomeVariant gets another entry.

[est31]

I've wondered about possible syntaxes. It seems here we have an exception from the rule of having to import the variant via use before being able to use the enum variant without :: (like, say, in patterns).

Personally I think it's okay to not be required to do offset_of!(Type, Type.field.Enum::Variant.0), just being able to do offset_of!(Type, Type.field.Variant.0), without need for an use Enum::* or use Enum::Variant;. So I think the syntax this PR proposes is fine.

[scottmcm]

Musing on syntax:

Would it be worth having some syntactic distinction between variant parts and field parts? After all, offset_of!(Option, Some) doesn't work.

Spitballing, offset_of!(Option, Some::0) or something?

(Dunno that this would be necessary, though. Just Some.0 is certainly unambiguous, and thus would absolutely work.)

EDIT: Oh, you mentioned this in the OP. Dunno how to choose here.

I started a zulip thread to try to think about things more: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.60offset_of!.60.20Syntax/near/384555143

---

I agree with @est31 that we don't need to type-qualify things, though, same as how field access in general isn't type-qualified.

[CAD97]

Some discussion w.r.t. syntax on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.60offset_of!.60.20Syntax

My proposed bikeshed color: offset_of!(Type, field, as Enum::Variant, field), with Enum::Variant being a name-resolved item path (like Type, unlike fields). This separates the items/types/variants from fields predictably.

macro_rules! matcher syntax

macro_rules! offset_of {
    ($Container:ty,
        $($($midfields:tt).+, as $Variant:path,)*
        $($fields:tt).+ $(,)?
    ) => { ... };
    // and for top-level enum types:
    ($Container:ty,
        as $TopVariant:path,
        $($($midfields:tt).+, as $Variant:path,)*
        $($fields:tt).+ $(,)?
    ) => { ... };
}

Requiring full item name lookup is tbf unnecessary since we do already know the type contextually, but the same applies to patterns and we don't use the contextual information there either. I'd expect _::Variant to work if/when it works for patterns.

The as could be dropped, but I think it's useful for clarity, as well as it allows spelling the inspection of a top-level enum offset_of!(Option::<T>, as Some, 0) instead of requiring something like perhaps offset_of!(Option::<T>, self, as Some, 0) to have a no-op field path (in order to distinguish between the item/type/variant name and field name(s)).

Whether the as Type segments are additionally permitted to assert the specific type at a point in the path in addition to traversing variants, it could go either way tbh. Maybe give every "type segment" of offset_of! a syntax of $($Container:ty)? $(as $Variant:ident)?,? E.g. offset_of!(Type, field, _ as Variant, field) and offset_of!(Option::<T> as Some, 0).

My opinion changes if the basic syntax changes. If offset_of!(Type.field) were permitted, I'd be fully on board with using offset_of!(Type.field.Variant.field). It's because the initial type is comma separated that I feel later type variants should also be comma separated.

[llogiq]

I'm personally not a fan of as Variant. While I understand the idea of distinguishing variants from fields (and we don't want to rely on upper- vs. lowercase here, they aren't mandatory after all), as is currently used only in conjunction with a type, not a variant.

So we either use ::Variant (but then should also allow e.g. offset_of!(Option<T>::Some.0) or rely on the fact that the type can only ever have variants or fields but not both at the same level (as per this PR).

[scottmcm]

For MIR we are using (val as Variant).field as syntax for accessing variant fields. I don't think it works well with the offset_of!() syntax though.

Yeah, that basically only works in MIR because of the RValue::Cast vs ProjectionElem::Downcast distinction.

In anything that would go in surface-like Rust, I don't think we can make that so cleanly. Any use of as would probably end up needing to be a fully-resolved type -- even with enum variant types -- and this wants something more like field access that wouldn't need to fully scope it. (Like this wants to be able to just say Bar because of the context, rather than needing to either use MyType::Bar; or have to say MyType::Bar.)

[llogiq]

Yeah, doing offset_of!(Type, comma-separated list of field or Variant::field) would probably minimize the implementation effort, be perfectly clear and fit into { $ty, $( $opt_var_field:path ),+ }.

[the8472]

The feature is unstable, so can we pick something and then bikeshed the stable syntax separately?

[llogiq]

I stand corrected, paths don't accept Variant::0. So the easiest way would be offset_of!(Type, Variant.field, field) (using a . instead of :: via an expr parser).

[est31]

and fit into { $ty, $( $opt_var_field:path ),+ }.

I don't think that path would work here, as we want to support tuple fields, and 0 isn't a valid path (nor is it an ident). edit: expr might work.

[llogiq]

@est31 I agree. When I checked it in the playground, it didn't work. Trying other options brought up the expr matcher in conjunction with . separating the field from the variant.

The nice thing is that ideally we want a (VariantIdx, FieldIdx) tuple per lookup, and using this structure means we can use the comma delimiter and then just parse (Ident | Number | Ident "." Number), using VariantIdx::FIRST_VARIANT if we don't have a given variant.

With that said, I'd be totally OK with unstably merging any syntax that makes it work and handling the other stuff later.

[scottmcm]

I agree with @the8472 in #114208 (comment) -- let's get this landed in nightly under a feature gate, and continue the syntax picking conversation on zulip.

I would vote for picking something as simple as possible in the macro that's consistent with offset_of!(Type, field_name) from the RFC, so maybe just allow offset_of!(Type, a, b, c, d), and keep the code you already have here for figuring out based on types which levels are variants. (I'd also be fine with merging the variant and field into one element of the list, but since the code already exists for token-at-a-time, might as well just use that unless a consensus evolves for something else.)

(I have some compiler code comments, but feel free to do or ignore those depending on the advice of the actual compiler reviewers here.)

[GKFX]

@wesleywiser @est31 This is now rebased and review comments are resolved.

[wesleywiser]

Thanks @GKFX!

@bors r+

[bors]

📌 Commit e742f80 has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

⌛ Testing commit e742f80 with merge 146dafa...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 146dafa to master...

[rust-timer]

Finished benchmarking commit (146dafa): 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)	-	-	0
Improvements ✅ (primary)	-2.5%	[-2.8%, -2.2%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.5%	[-2.8%, -2.2%]	2

Cycles

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

Binary size

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

Bootstrap: 635.994s -> 638.45s (0.39%)
Artifact size: 304.49 MiB -> 304.48 MiB (-0.01%)