Support field-wise CoerceShared reborrows

[P8L1]

View all comments

This PR extends generic shared reborrows so that CoerceShared validates and lowers source-to-target structs field by field, rather than relying on a same-layout, transmute-like copy.

The core change is a shared rustc_middle::ty::reborrow helper that computes the field correspondence used by CoerceShared validation, borrow checking, const-eval, and codegen.

The correspondence rules are:

• Named structs match non-PhantomData data fields by name.
• Tuple structs match non-PhantomData data fields by position.
• PhantomData fields are ignored.
• Every target data field must correspond to a source data field.

CoerceShared impl validation now checks each corresponding field relation. A field relation is accepted when the field is:

• Copy-compatible,
• recursively CoerceShared-compatible, or
• a mutable-reference-to-shared-reference reborrow.

The validation also rejects mismatched field styles, missing source fields, mismatched reborrow lifetimes, and inaccessible fields with targeted diagnostics.

Borrowck now adds shared generic reborrow constraints recursively through the validated field relations, while still issuing the loan for the original source place as a whole. This ensures source-only fields remain protected for the inferred target lifetime when the target omits fields from the source.

Const-eval and codegen now lower shared generic reborrows recursively into the target fields instead of treating the operation as a transmute-like copy. This covers nested CoerceShared fields and layout-changing source/target pairs.

Fixes

Fixes #156566.
Fixes #156309.
Fixes #156315.

PR scope

I did not split these into smaller PRs because the issues mostly share the same root cause: CoerceShared needed a field-by-field validation and lowering model. So when making this, I just decided to write it in a way that will fix the issues anyway.

Tracking

#145612
https://rust-lang.github.io/rust-project-goals/2025h2/autoreborrow-traits.html

CC. @aapoalas, @dingxiangfei2009
r? @RalfJung

[rust-bors]

🔨 5 commits were squashed into b8e47e8.

[rust-bors]

Unclosed quote in argument. Run @bors help to see available commands.

[P8L1]

@bors squash msg="Support field-wise CoerceShared reborrows"

[rust-bors]

🔨 7 commits were squashed into 8987e4a.

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

This PR changes MIR

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

The Cranelift subtree was changed

cc @bjorn3

[rustbot]

r? @folkertdev

rustbot has assigned @folkertdev.
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 73 candidates
• Random selection from 17 candidates

[rustbot]

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

[RalfJung]

Why are you asking for my review here? I have nothing to do with this feature and don't have capacity to take on a new feature, especially not a massive PR like this.

@rustbot reroll

[P8L1]

Why are you asking for my review here? I have nothing to do with this feature and don't have capacity to take on a new feature, especially not a massive PR like this.

@rustbot reroll

Oh I'm Sorry I did not think much.

I inferred from #156955 that you might be the right person to look specifically at the CTFE/Miri part, since that PR also touched reborrow const-eval/interpreter code and you reviewed it. But I understand now that this might be a bit to much to review on top of the work you already have..

Once again sorry, have a nice day

[RalfJung]

Looks like this is associated with https://rust-lang.github.io/rust-project-goals/2026/reborrow-traits.html ?
Cc @aapoalas -- is there a long-term plan for this proposal? If such non-trivial MIR semantics are needed, a "small" compiler team ask may not quite reflect the amount of work this may take. Also see this thread.

[RalfJung]

r? @oli-obk
who is the compiler liaison for that goal.

Also @P8L1 when you do work for a project goal, that's a good thing to mention in the PR description. If you're not aware of the project goal here, please coordinate with @aapoalas and @oli-obk.

[P8L1]

r? @oli-obk who is the compiler liaison for that goal.

Also @P8L1 when you do work for a project goal, that's a good thing to mention in the PR description. If you're not aware of the project goal here, please coordinate with @aapoalas and @oli-obk.

Hi Ralf, sorry, I always thought the tracking issue was enough. Thanks for the correction, I won't make the mistake again!

[RalfJung]

Fair, the tracking issue should in principle suffice. But not everyone always clicks through all the links. ;)

[dingxiangfei2009]

Hello @P8L1 and thank you for taking interest in the reborrow work.

With per-field reborrowing the proposed design will break away from a few fundamental but important assumptions and intended use cases of this language feature. A design document would certainly bring @aapoalas and me onto the same page and help us understand why the extension would be desirable. Let us chat on Zulip as well if you need any help.

[P8L1]

Hello @P8L1 and thank you for taking interest in the reborrow work.

With per-field reborrowing the proposed design will break away from a few fundamental but important assumptions and intended use cases of this language feature. A design document would certainly bring @aapoalas and me onto the same page and help us understand why the extension would be desirable. Let us chat on Zulip as well if you need any help.

Thanks, that makes sense.

I wrote up a PR-specific design note here please review it and share your thoughts so this PR can proceed!