DateComponents, URLRequest, URLComponents: Fix hashing #1656
Conversation
|
@swift-ci please test |
TestFoundation/Utilities.swift
Outdated
|
|
||
| // Check that mutating `object` via the specified key path affects its | ||
| // hash value. | ||
| func _checkHashableMutations<Source: Hashable, Target: Hashable, S: Sequence>( |
There was a problem hiding this comment.
I know these are a ton of arguments and it's essentially fileprivate, but honestly I'd have a more descriptive set of labels because it is really hard to parse the invocations above at a glance.
e.g.: _checkHashing(of type, matches type, initialValue:, copyHandler:, byMutating keyPaths, throughRange:)
That's a good question! I should make a Darwin version of these tests -- I'm adding it to my to do list. |
|
@swift-ci please test and merge |
|
Oh, swift-ci can’t merge here! @swift-ci test |
|
@lorentey There is an Xcode project, |
|
I managed to run these tests on Darwin's Foundation, and filed rdar://problem/43422017 with my findings. While Darwin Foundation (erroneously) neglects to mix some of the properties that affect equality into the hash value, I believe there is no need for swift-corelibs-foundation to emulate this behavior. (Emulating exact hash values would not be a worthy exercise anyway, and given the lack of random seeding, it may even be actively harmful to do so in server contexts.) So I think the definitions can stay as defined here. |
|
Now if only I could get PR testing to update GitHub status... The tests seem to finish successfully, but the PR stays yellow. @swift-ci test |
This PR collects fixes previously submitted separately as #1645, #1646 and #1648, fixing the implementation of hashing for the following Foundation types:
DateComponentsNSDateComponentsURLRequestNSURLRequestURLComponentsNSURLComponentsNote that this isn't a full audit of Foundation hashing -- this was the bare minimum necessary for #1649. I suspect there may be more types with issues similar to these.
Resolves: