[4.0] Make all CF types Equatable and Hashable. #9401
Conversation
Like NSObject, CFType has primitive operations CFEqual and CFHash, so Swift should allow those types to show up in Hashable positions (like dictionaries). The most general way to do this was to introduce a new protocol, _CFObject, and then have the importer automatically make all CF types conform to it. This did require one additional change: the == implementation that calls through to CFEqual is in a new CoreFoundation overlay, but the conformance is in the underlying Clang module. Therefore, operator lookup for conformances has been changed to look in the overlay for an imported declaration (if there is one). This re-applies 361ab62, reverted in f50b1e7, after a /very/ long interval where we decided if it was worth breaking people who've added these conformances on their own. Since the workaround isn't too difficult--- use `#if swift(>=3.2)` to guard the extension introducing the conformance---it was deemed acceptable. https://bugs.swift.org/browse/SR-2388
|
@swift-ci Please test |
|
@swift-ci please test source compatibility |
|
you should probably check CFAllocator (because it has slightly different behavior than the other CF types when it comes to bridges) as well as bridged subclasses, e.g. a subclass of NSString as a CFString and validating the appropriate hash function is called |
|
Thanks. I'm not sure whether I care that much about people trying to hash or compare allocators—it'll be no worse than doing it in C—but I'll check. The bridging is a good end-to-end test that I'll add on master. |
|
@lplarson: The source compat failures all seem unrelated to this change. Was there something up with that? https://ci.swift.org/job/swift-PR-source-compat-suite/52 |
|
Per the allocator that one was just a class that I knew followed a slightly different layout pattern and could cause "issues" |
|
@jrose-apple Expected failures haven't been configured for 4.0 yet. I'm working on that today. |
Cherry-pick of #4568 to the 4.0 branch. Reviewed by @DougGregor.
SR-2388 / rdar://problem/32003073