[stdlib] Make sure _SwiftNewtypeWrapper hashes the same way as its RawValue #15990
Conversation
…wValue _SwiftNewtypeWrapper forwarded hashValue to its rawValue, but it failed to do the same for _hash(into:), which resulted in the wrapper struct having subtly different hashing than the raw value. This violated an implicit invariant when dictionaries/sets of such types were bridged to Objective-C through AnyHashable, leading to nondeterministic but frequent crashes. rdar://problem/39398060
|
@swift-ci please smoke test and merge |
|
(Tests that will cover this scenario are being developed in #15939.) |
|
|
||
| @inlinable // FIXME(sil-serialize-all) | ||
| public func _hash(into hasher: inout _Hasher) { | ||
| hasher.append(rawValue) |
There was a problem hiding this comment.
Nice catch. Is this something that users are likely to run into, or is it because of the special relationship between newtype'd imports and bridging?
There was a problem hiding this comment.
The crash was caused by a particularly weird interplay between _hash(into:), newtype, AnyHashable and bridging.
Luckily, I don't see how it could apply to user code. For example, struct Foo below produces the same hashValue as its label, but it doesn't hash the same way through _hash(into:). This isn't an issue, though, because the only way to put them in the same hash table is through AnyHashable, and since they don't have the same AnyHashable representation, they wouldn't compare equal even if they had matching hashes:
struct Foo: Hashable {
var label: String
var hashValue: Int { return label.hashValue }
static func ==(left: Foo, right: Foo) -> Bool { return left.label == right.label }
}
Foo(label: "foo").hashValue == "foo".hashValue // ==> true
(Foo(label: "foo") as AnyHashable) == ("foo" as AnyHashable) // ==> false
let s: Set<AnyHashable> = [Foo(label: "foo"), "foo"]
s.count // ==> 2The only visible effect seems to be that Dictionary/Set ordering is different for Foo and String, but hash table ordering is explicitly unstable, so code that depends on that is already broken.
There was a problem hiding this comment.
Okay. Imported newtypes are specifically weird because we need hashing consistency for the newtype, the type it wraps, and potentially the bridged type (SomeNewType/String/NSString), so yeah--unlikely to affect anyone else.
_SwiftNewtypeWrapperforwarded hashValue to itsrawValue, but it failed to do the same for_hash(into:), which resulted in the wrapper struct having subtly different hashing than the raw value.This violated an implicit invariant when dictionaries/sets of such types were bridged to Objective-C through
AnyHashable, leading to nondeterministic but frequent crashes.rdar://problem/39398060