Mutable closure captures through opaque casts

[amirHdev]

fixes #160120
Preserve place semantics for opaque projections in closure captures instead of lowering them through ExprKind::Use and ensures mutable captures through TAIT opaque casts are validated by borrowck with both solvers

[rustbot]

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

Some changes occurred in match checking

cc @Nadrieril

[rustbot]

r? @khyperia

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

[khyperia]

Would you mind describing a bit why a new THIR ExprKind is needed? This seems like it's a bug with the old solver, the new solver is able to error on this without requiring a new THIR node kind. How is it able to do so? Why is a new node kind needed for the old solver? If there's a good reason, do we want to only create this node kind if the old solver is in use?

[amirHdev]

@khyperia
I looked for differences between the two solvers
with the old solver capture analysis keeps the base type as the opaque T and records the capture path as
OpaqueCast(Foo) -> Field(0)
with the next solver the base is already resolved to Foo and the capture path is only
Field(0)
The current THIR conversion lowers the old solver OpaqueCast to ExprKind::Use and since Use has value semantics during MIR construction it copies foo into a temporary and borrows temporary.0instead of borrowing foo.0 which is why the old solver misses E0596. the next solver directly borrows foo.0 so borrowck reports the error.
the new THIR node preserves the existing opaque cast as a place operation until MIR where it becomes ProjectionElem::OpaqueCast and keep MutBorrowKind::Default for this case asClosureCapture assumes that the mutation inside the closure will independently produce an error but under the old solver that mutation is lowered through the temporary and no such error is produced. that preserving the place cast alone while retaining ClosureCapture still accepts the program.

I tried replacing the captured place's opaque base type with the hidden type instead but the actual MIR local remains opaque. projecting a field from it without OpaqueCast violates MIR place typing and causes an ICE.
A closure specific side channel could carry the projection directly to MIR but that would require threading additional capture metadata through duplicating place lowering. preserving it as a THIR place expression appears to be the more direct representation

[lcnr]

I feel fairly uncomfortable with changes here and think that OpaqueCast is quite fragile.

The new solver handles this correctly by normalizing opaque types in the defining scope. I think we should keep #160120 as an error with the old solver as properly fixing this requires properly normalizing opaque types which is too large of a change given the impending next-solver stabilization

[amirHdev]

@lcnr that makes sense thanks for clarifying. I’ll close the PR then