Fix unit struct/enum variant in destructuring assignment

[compiler-errors]

See https://github.com/rust-lang/rfcs/blob/master/text/2909-destructuring-assignment.md#guide-level-explanation, "including unit and tuple structs"

Fixes #94319

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[lcnr]

looks good to me, @rust-lang/lang this PR adds unit structs and enum variants to destructuring assignment as insta stable. (see the test)

This will be quite infrequently used and imo is a small enough papercut that most people will not add a feature for this. It is also a consistency fix and was part of the original RFC.

Still want some kind of signoff here.

[petrochenkov]

I'll check the implementation because there was some tricky details with destructuring assignments to tuple structs.

As for usefulness, this certainly doesn't look useful.
The only possible motivation here is consistency in the sense "if the expression looks like a pattern, then the assignment desugaring is possible".

[lcnr]

As for usefulness, this certainly doesn't look useful.

I guess one might use it for

struct ZstToken;
fn returns_value_and_token() -> (u32, ZstToken) { ... }

let mut x = 0;
// With this PR:
(x, ZstToken) = returns_value_and_token();
// Without it:
x = returns_value_and_token().0;
// ^ won't detect if the return type of that function changes in the future

[petrochenkov]

there was some tricky details with destructuring assignments to tuple structs

Ok, as expected, the implementation is subtly incorrect in presence of associated items and Self.

@compiler-errors
Could you repeat the setup used for the ExprKind::Call case exactly?
I.e. introduce analogues for fn extract_tuple_struct_path and fn expected_in_tuple_struct_pat, but for path patterns.

(I'd also recommend to avoid additional refactorings like moving self.lower_expr(lhs).)

[lcnr]

r? @petrochenkov

[compiler-errors]

Rebased and addressed comments

[petrochenkov]

Thanks!
r=me on the implementation.

I'm going to reroute this to the lang team for some kind of approval.

[nikomatsakis]

@bors r+

We discussed this in the @rust-lang/lang meeting. Given that this is a bug-fix that is making the behavior match the RFC as specified, and that the old code did not compile (rather than compiling with different behavior, for example), we don't feel an FCP is necessary.

Thanks @petrochenkov for raising it to our attention!

[bors]

📌 Commit 17f5c4d has been approved by nikomatsakis

[bors]

⌛ Testing commit 17f5c4d with merge 1b2e0b6...

[bors]

☀️ Test successful - checks-actions
Approved by: nikomatsakis
Pushing 1b2e0b6 to master...

[rust-timer]

Finished benchmarking commit (1b2e0b6): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression