"Structural match" annotations should be moved from struct/enum items to impl items

[petrochenkov]

"Structural match" property of a type means that the constants of this type can be used in patterns (#31434) or in const generics in the future.

Right now this property can be given to a type in two ways:

• #[structural_match] attribute, rarely used, PhantomData is the only example.
• If the struct/enum has both #[derive(PartialEq)] and #[derive(Eq)] then it's marked as "structural match". Derives cannot modify the items they are applied to, so this tracking is done through a special table in resolver (which is kind of a hack).

To avoid hacks we need to pass the knowledge about "structural match" not through types themselves, but through impls on them (which can be generated by derives easily).

The condition for the type being "structural match" is:

• PartialEq methods are derived so their behavior is fully known to the compiler.
• Eq is implemented, but not necessarily derived, it's just a marker without methods.

So, the "structural match" annotation needs to be generated by derive(PartialEq) in the form of either

• an attribute #[structural_match] impl PartialEq for ... (in this case the const check will be "implements Eq + implements PartialEq + the PartialEq impl has the attribute"), or
• an impl of some third trait impl StructuralMatch for ... (in this case the const check will be "implements Eq + implements StructuralMatch").

cc #63248 @matthewjasper @varkor @Centril @pnkfelix

[Centril]

cc #60286

[matthewjasper]

cc #61188

[pnkfelix]

I'm in favor of the second suggested approach, namely:

an impl of some third trait impl StructuralMatch for ... (in this case the const check will be "implements Eq + implements StructuralMatch").

[pnkfelix]

(i've been working on this and have a plausible prototype. I hope to have a PR up soon.)