next_solver: Fix Field::OFFSET normalization

[Dnreikronos]

Fixes #162338

With gca_const_items (previously generic_const_args), Field::OFFSET becomes a type-system constant. MIR normalization sends it to the builtin Field candidate, which assumes it's looking at an associated type and panics on ProjectionConst.

The candidate now handles type and const projections separately. I think this is the right place to fix it because the constant reaches the right candidate, but that candidate is missing the const case. I used evaluate_const_and_instantiate_projection_term, the same helper used for ordinary associated constants. Builtin instance resolution selects the default Field::OFFSET body, and the intrinsic gets the offset from the target layout. Constants that are still too generic become rigid aliases; unresolved inference stays ambiguous. The existing Field trait checks still apply.

Added a gca_const_items revision to the offset test, plus generic structs with u8 and u64 fields. The reduced case also has a regression test with MIR output enabled, since a metadata-only check doesn't reach the crash. With the current feature names, the original example compiles now, and the reduced one reports the expected errors without an ICE.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 76 candidates
• Random selection from 21 candidates

[nnethercote]

This needs a more appropriate reviewer:

r? @lcnr

[lcnr]

hmm, unsure about this 🤔

what is the builtin constant we're evaluating here? also, given this is builtin, should we not match on the lang item here to deal with changes to this trait?

View changes since the review

[Dnreikronos]

It's OFFSET on Field. Its default body in core calls the field_offset intrinsic with Self. The evaluator goes through builtin instance resolution, which selects that body, and the intrinsic computes the offset from the layout.

I used the existing evaluator because it already handles generic constants and unresolved inference. The part I'd change is the catch-all ProjectionConst arm. It accepts any associated constant on Field, so the code relies on OFFSET being the only one.

I think matching the field_offset lang item here is cleaner. It makes the supported constant explicit, and adding another constant to the trait would require us to decide how to handle it. I'd keep the evaluator and extend the solver's lang-item lookup to support const projections. Does that match what you had in mind?

[lcnr]

@rustbot author

[rustbot]

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

[Dnreikronos]

@rustbot ready

[rustbot]

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.