Implement primitive equality

[eernstg]

Cf. dart-lang/language#2106 for spec updates, https://dart-review.googlesource.com/c/sdk/+/279165 for tests, and dart-lang/language#2108 for background.

This issue is concerned with the implementation of support for primitive equality.

We have previously had the notion of 'a primitive operator ==', which was improperly ignoring hashCode, but otherwise capturing the notion that an object has an implementation of equality which is statically known, such that it can be evaluated at compile-time. We required that an object must have a primitive operator == in a few situations, e.g., in order to be a member of a constant set. With the upgrade to primitive equality, we have the same constraints, except that both hashCode and operator == must be primitive in this sense.

The tests show that the analyzer does not report the situation where a member of a constant set has an overriding declaration of hashCode (this is a new error, so it's no surprise that we need an update). The CFE would presumably need the same updates, but it only reports a single 'Constant evaluation error' for the constant set/map as a whole, which may or may not be the intended response.

---

Subtasks:

• [analyzer] Implement primitive equality #51046.
• [cfe] Implement primitive equality #51047.

[bernaferrari]

Hey, really really dumb question, but this is going to allow const [1, 2,3] == const [1, 2, 3] without listEquals? I guess for now, [1, 2, 3] != [1, 2, 3], right?

[eernstg]

Not a dumb question, I don't think we have that concept! ;-)

const [1, 2, 3] == const [1, 2, 3] is already true, because those two constant expressions evaluate to the exact same object (because of canonicalization).

In contrast, [1, 2, 3] == [1, 2, 3] evaluates to false because those two expressions are non-constant, and hence each of them evaluates to a fresh, mutable list. There's no way it would yield a useful semantics if a non-constant (hence mutable) list literal could be implicitly taken to evaluate to the same object as a different list literal, or even the same list literal when and if it gets evaluated another time. That would necessarily be considered to be a bug, so we don't do that.