[mir-opt] SRoA away the tuple in `match (a, b)`

[scottmcm]

I was looking at this derived ==:

#[derive(PartialEq)]
pub enum Foo<A, B> {
    Bar(A),
    Qux(B),
}

The MIR ends up including https://rust.godbolt.org/z/1e7KWjf5M

    bb1: {
        _6 = (copy _1, copy _2);
        _18 = deref_copy (_6.0: &Foo<A, B>);
        _9 = discriminant((*_18));
        switchInt(move _9) -> [0: bb4, 1: bb5, otherwise: bb3];
    }

    bb4: {
        _19 = deref_copy (_6.1: &Foo<A, B>);
        _7 = discriminant((*_19));
        switchInt(move _7) -> [0: bb7, otherwise: bb3];
    }

    bb5: {
        _20 = deref_copy (_6.1: &Foo<A, B>);
        _8 = discriminant((*_20));
        switchInt(move _8) -> [1: bb6, otherwise: bb3];
    }

    bb6: {
        _21 = deref_copy (_6.0: &Foo<A, B>);
        _14 = &(((*_21) as Qux).0: B);
        _22 = deref_copy (_6.1: &Foo<A, B>);
        _15 = &(((*_22) as Qux).0: B);
        _16 = &_14;
        _17 = &_15;
        _0 = <&B as PartialEq>::eq(move _16, move _17) -> [return: bb8, unwind continue];
    }

It would be nice if we'd just completely removed that _6 = (copy _1, copy _2);, especially since it's a tuple-of-references so there's really nothing scary about it.

I noticed that this isn't handling Rvalue::CopyForDeref

rust/compiler/rustc_mir_transform/src/sroa.rs

Lines 133 to 150 in fda35a6

	fn visit_assign(
	&mut self,
	lvalue: &Place<'tcx>,
	rvalue: &Rvalue<'tcx>,
	location: Location,
	) {
	if lvalue.as_local().is_some() {
	match rvalue {
	// Aggregate assignments are expanded in run_pass.
	Rvalue::Aggregate(..) | Rvalue::Use(..) => {
	self.visit_rvalue(rvalue, location);
	return;
	}
	_ => {}
	}
	}
	self.super_assign(lvalue, rvalue, location)
	}

Maybe that would solve it?

[cjgillot]

@scottmcm I don't understand this issue. If you add -O to your command line, the tuple goes away.

[scottmcm]

Looking at it again, I don't understand either 😅