fix(reborrow): recursive implementation

[aapoalas]

View all comments

If Reborrow finds '&'a mut T' fields where 'a is the Reborrowed type's first lifetime parameter (currently the only lifetime that is allowed to reborrow) then it inserts a Deref and borrow of the T, and likewise if it finds a 'T: Reborrow' field then the field type is recursed into.

This makes Reborrow always produce the correct borrow checking logic at the cost of most probably being inconsiderately expensive. The thinking is that performance will be a followup consideration.

r? @oli-obk

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

This PR changes MIR

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

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to constck

cc @fee1-dead

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

[rustbot]

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

[oli-obk]

Started a review a few days ago, but other things came in between, so nothing architectural yet, but docs are always useful

View changes since this review

[rustbot]

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

[oli-obk]

@bors delegate+

r=me with remaining things resolved

[rust-bors]

✌️ @aapoalas, you can now approve this pull request!

If @oli-obk told you to "r=me" after making some further change, then please make that change and post @bors r=oli-obk.

View changes since this delegation.

[aapoalas]

@bors squash

[rust-bors]

🔨 16 commits were squashed into 5686e56.

[aapoalas]

All of the comments should now be handled, and I've also decided on the next steps:

1. CoerceShared will lose the type argument and go back to an associated type.
2. Despite me already deciding the other way around, CoerceShared will not be written as impl<'a: 'b, 'b> CoerceShared for Source<'a> { type Target = Target<'b>; }. This isn't even allowed as 'b is unconstrained. What we'll do instead is that in borrowck we'll project from Source<'a> into type Target = Target<'a> and then do a normal relate_types from the Target<'a> into our assignment target's Target<'b>.
3. I'll have to look into whether we'll still need a custom TypeRelation for CoerceShared so that silly impls like the following won't cause havoc:

struct Source<'a, 'b> {
  a: &'a mut A,
  b: &'b mut B,
}

struct Target<'a, 'b> {
  a: &'a A,
  b: &'b B,
}

impl<'a, 'b> CoerceShared for Source<'a, 'b> {
  type Target = Target<'b, 'a>; // Note: flipped lifetimes.
}

And if we do need that, do we really still need the projection? I guess we do to catch implementations like:

impl<'a, 'b> CoerceShared for Source<'a, 'b> {
  type Target = Target<'static, 'static>;
}

4. I believe I'll eventually be adding the following blanket impls:

impl<T: Copy> Reborrow for T {}
impl<T: Copy> CoerceShared for T {
  type Target = T;
}

If the compiler can reason about reborrows of generic T: Reborrow then this'd mean someone could write code that is generic over &mut T and &T where a particular trait (doing actual useful work) is implemented for both. That seems potentially quite useful.

@bors r=oli-obk

[rust-bors]

📌 Commit 5686e56 has been approved by oli-obk

It is now in the queue for this repository.