Skip to content

Make all CF types Equatable and Hashable. #4417

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Aug 19, 2016
Merged

Make all CF types Equatable and Hashable. #4417

merged 1 commit into from
Aug 19, 2016

Conversation

jrose-apple
Copy link
Contributor

  • Explanation: Now that we've removed implicit bridging, making a CFDictionary to pass to, say, CoreGraphics is rather difficult to do easily. Ideally we'd want a CFString-keyed dictionary (since all the global constants are CFStrings), but we can't do that without CFString being Hashable. However, all CF types are hashable in the same way as NSObject: there's a standard CFHash function that works across types. This commit adds a new protocol, _CFObject, which includes Hashable and Equatable implementations; it also tweaks protocol checking to allow operator requirements to be found in overlays for a particular module. Note that this will break anyone who implemented Hashable for a CF type themselves.
  • Scope: Affects all imported CF types. Sema change should not affect any existing behavior because no imported types were using protocols with operator requirements that wouldn't be found.
  • Issue: SR-2388
  • Reviewed by: @jckarter and @DougGregor
  • Risk: Medium-low. Most likely very few people were doing this, and the Sema change shouldn't affect anything.
  • Testing: Added new regression tests.

Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
All supported platforms @swift-ci Please smoke test and merge
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library only for macOS. Simulator standard libraries and
    device standard libraries are not built.
  3. lldb is not built.
  4. The test and validation-test targets are run only for macOS. The optimized
    version of these tests are not run.

A smoke test on Linux does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library incrementally.
  3. lldb is built incrementally.
  4. The swift test and validation-test targets are run. The optimized version of these
    tests are not run.
  5. lldb is tested.

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
All supported platforms @swift-ci Please test and merge
OS X platform @swift-ci Please test OS X platform
OS X platform @swift-ci Please benchmark
Linux platform @swift-ci Please test Linux platform

Lint Testing

Language Comment
Python @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@jrose-apple
Make all CF types Equatable and Hashable.
45e2feb 
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).

https://bugs.swift.org/browse/SR-2388
(cherry picked from commit 361ab62)
@jrose-apple jrose-apple added this to the Swift 3.0 milestone Aug 19, 2016
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test macOS

@jrose-apple
Copy link
Contributor Author

@parkera, any objections?

parkera
parkera reviewed Aug 19, 2016
View reviewed changes
stdlib/public/SDK/CoreFoundation/CoreFoundation.swift
@@ -0,0 +1,23 @@
//===----------------------------------------------------------------------===//
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please name this file something more descriptive than CoreFoundation.swift. CFObject.swift maybe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately our CMake setup currently takes the name of the result file from the name of the first file in the module.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would then prefer to see an empty CoreFoundation.swift and this stuff in a more descriptive place.

I really don't like how Foundation.swift became a dumping ground for whatever needed to be put there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, will fix in master. I'll see if the CMake stuff is easy to change, too.

@ematejska ematejska assigned ematejska and jrose-apple and unassigned ematejska Aug 19, 2016
@jrose-apple jrose-apple merged commit 726b2c7 into swiftlang:swift-3.0-branch Aug 19, 2016
@jrose-apple jrose-apple deleted the swift-3-Hashable-CF branch August 19, 2016 22:42
@gparker42 gparker42 mentioned this pull request Aug 20, 2016
Merged
@gparker42
Copy link
Contributor

Reverting. New test Interpreter/SDK/cf.swift fails in two places when built with --test-optimized. I don't know if it's a bug here or a miscompile of this code.
https://ci.swift.org/view/swift-3.0-branch/job/oss-swift-3.0_tools-RA_stdlib-RDA_test-simulator/77/

@gparker42 gparker42 mentioned this pull request Aug 20, 2016
Merged
1 task
@gparker42
Copy link
Contributor

Also reverting #4394 on the 3.0 branch.

@belkadan belkadan mentioned this pull request Aug 19, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@jrose-apple jrose-apple

Labels
None yet
Projects
None yet
Milestone
Swift 3.0
Development

Successfully merging this pull request may close these issues.
4 participants
@jrose-apple @gparker42 @parkera @ematejska