Mark a few libcore types as structurally equal if their contents are

[oli-obk]

• str was just missing a marker
• arrays of StructuralEq types are already treated as StructuralEq in the rustc pattern match logic
• tuples of StructuralEq types are also already treated as StructuralEq
• [T] types shouldn't behave differently from arrays in pattern matching, so I marked them as StructuralEq if their contents are.
• &T types where T: StructuralEq cannot have a custom Eq or PartialEq impl, they must be using the generic impl. Thus the user cannot have created any handwritten impls for &UserType, thus we can treat them as StructuralEq.

r? @petrochenkov

cc @pnkfelix @nikomatsakis @ecstatic-morse

cc #31434

[petrochenkov]

What is the goal here, using Structural(Partial)Eq in bounds or removing hard-coded cases from the compiler?

Seems like these impls are not currently necessary for constant pattern matching because everything built-in is known to the compiler without them.

[ecstatic-morse]

It's actually not correct to bound the generic parameters by Structural{Partial,}Eq. The semantics for these marker traits are quite subtle: an implementation of Structural{Partial,}Eq guarantees only that the PartialEq impl for that type calls the PartialEq impl of each of its fields. It does not guarantee that the type of each of those fields is itself Structural{Partial,}Eq.

I can try to explain why this needs to be the case, but that might be easier to do synchronously.

[nikomatsakis]

Hmm, I wonder if all of these things are true in the face of specialization -- ah, I guess they are. e.g. the &T impls don't default a default fn, so the user should not be able to specialize it with some weird type. OK.

[nikomatsakis]

@ecstatic-morse I don't really understand your comment, I'm afraid.

[oli-obk]

There was some discussion in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Structural.20match.20marker.20traits/near/192927648

[petrochenkov]

r? @ecstatic-morse or @eddyb
(This seems to be tied to other parts of consteval, in which I'm not an expert.)

[oli-obk]

This is not quite what we want, let's keep discussing in #31434