Unnecessary 'cannot bind by-move with sub-bindings' with `bindings_after_at`

[comex]

The following code (playground link) attempts to move a struct while using a sub-binding to copy one of its fields:

#![feature(bindings_after_at)]

struct NonCopyStruct {
    copy_field: u32,
}

fn foo(x: NonCopyStruct) {
    let y @ NonCopyStruct { copy_field: z } = x;
}

On nightly, it produces two errors:

error[E0007]: cannot bind by-move with sub-bindings
 --> src/lib.rs:8:9
  |
8 |     let y @ NonCopyStruct { copy_field: z } = x;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ binds an already bound by-move value by moving it
error[E0382]: use of moved value: `x`
 --> src/lib.rs:8:41
  |
7 | fn foo(x: NonCopyStruct) {
  |        - move occurs because `x` has type `NonCopyStruct`, which does not implement the `Copy` trait
8 |     let y @ NonCopyStruct { copy_field: z } = x;
  |         --------------------------------^--
  |         |                               |
  |         |                               value used here after move

However, it would be sound to allow this, since it's equivalent to copying the field before or after moving the struct.

(There are no errors if the struct does implement Copy.)

[Centril]

So the only interaction with #![feature(bindings_after_at)] here is that you're now allowed to mention bindings after @. The feature gate does nothing beyond removing a call to check_legality_of_bindings_in_at_patterns which raises an error on any bindings in the subpattern of ident @ subpattern.

If you also enable #![feature(move_ref_pattern)], then that removes a call to check_legality_of_move_bindings from which the first error is coming. The second error comes from the borrow checker.

cc @matthewjasper

[matthewjasper]

This is the same as

fn foo(x: NonCopyStruct) {
    let y = x;
    let NonCopyStruct { copy_field: z } = x;
}

[Centril]

I tried to change this to:

fn foo(x: NonCopyStruct) {
    let NonCopyStruct { copy_field: z } = x;
    let y = x;
}

in MIR lowering by adjusting the visiting order in two places, but that didn't change the outcome. Perhaps that's because of the treatment of _?

At any rate, guaranteeing the visiting order here seems suboptimal wrt. for example making x @ y a true intersection pattern and y before x seems contrary to LTR reading order.