[ObjectiveC] Selector: Synthesize Equatable and Hashable

[lorentey]

(This PR was originally part of #20685.)

SE-0206 deprecated hashValue as a Hashable requirement, replacing it with hash(into:).

This PR removes the explicit Selector.hashValue implementation, allowing the compiler to provide a (faster) synthesized Hashable implementation, based on hash(into:). For symmetry, it also removes the explicit definition of ==. (The compiler-synthesized pointer comparison is documented to have the same semantics as sel_isEqual.)

[lorentey]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - dc44cc7bd08b827425fdf3728dcf08d9b52ca585

[jrose-apple]

Faster because it's inlinable, or faster because the compiler-synthesized definition is going to do extra work? Because if we're just concerned about the latter, we could reasonably special-case single-element structs.

[lorentey]

@jrose-apple The compiler-synthesized hash(into:) works by feeding hashValue to the hasher, which spawns a brand new Hasher to calculate a hash value for the opaque pointer. This is about four times more work than simply feeding the pointer bits to the supplied hasher.

The compiler can't really do a better job at synthesizing hash(into:), since there is an explicit hashValue implementation.

(I'm much more concerned about moving the remaining parts of stdlib away from hashValue than any immediate performance benefits.)

[jrose-apple]

If we could still make ABI-breaking changes, removing hashValue would be a better change, right? Just to be clear?

[lorentey]

Yeah, removing hashValue as a protocol requirement (and converting it into an extension property) would be the ideal end goal.

However, doing that now would be massively source-breaking; we've only introduced hash(into:) in 4.2, and we're not even emitting deprecation warnings for hashValue implementations yet. (That's hopefully coming soon -- see #20685)

Update: Ah, I see what you mean! We could safely remove the hashValue definition from Selector. This wouldn't even be an ABI-breaking change, since the compiler would just generate a functionally equivalent one from hash(into:). We should do that!

[jrose-apple]

The difference is that it won't be inlinable, though.

[lorentey]

Luckily, the current definition isn't inlinable either. (This is probably fine -- it's a non-generic struct.)

[jrose-apple]

Oh, I'm getting your PRs mixed up. :-) All right, great!

[lorentey]

Done!

@swift-ci smoke test

[jrose-apple]

…and then the next step is that you don't need hash(into:) either, because that's the default implementation. :-)

[lorentey]

Hah, you're right! It's so rare we can use Hashable synthesis in the stdlib, my poor brain can't handle it. :-)

[lorentey]

Hm, removing the hash(into:) definition is probably inadvisable unless we do the same to ==. (We should emit a warning in case Hashable is synthesized, but Equatable isn't.)

The equality operator currently calls sel_isEqual(_, _). Is it safe to compare the pointers directly? (If not, then we probably need to rethink hashing...)

[jrose-apple]

It looks like sel_isEqual is documented to be equivalent to ==, so we should be okay.

[lorentey]

OK, I'll take a deep breath and remove both explicit implementations then.

[lorentey]

Third time's the charm!

@swift-ci smoke-test

[lorentey]

@swift-ci smoke-test

[lorentey]

@swift-ci please smoke test