Use CoreFoundation from Swift #381
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Need to re-evaluate everything in this commit.
-Wthread-safety-anaysis -Wcast-qual -Wunused-parameter
https://github.com/apple/swift-corelib-foundation/pull/3004 Subject: [PATCH] [runloop] Set up some symbols for generic code. CFRunLoop has a recurring abstraction for platform-specific code, but it is a little leaky. Plug these leaks: ensure `MACH_PORT_NULL` in the generic, non-platform context is rewritten as `CFPORT_NULL`, and ensure that `kern_return_t` and `KERN_SUCCESS` are defined properly. [runloop] Remind porter these stubs are required. New platforms must define these types and functions; it is incorrect to not have #else cases here. [runloop] Implement runloop abstraction for BSD. [runloop] Ensure timing arithmetic is done in ns. Fixes SR-14288. [runloop] Avoid pthread_main_np on OpenBSD. During runloop testing, log messages suggest that the runloop thinks the main thread has exited and certain runloop operations don't actually proceed. The flag for denoting when the main thread has exited is set in the thread-specific data destructor `__CFTSDFinalize`. This function detects whether the thread in question is the main thread via `pthread_main_np`, and has been observed in debugging this problem to return 1 on apparently non-main threads on OpenBSD. This obviously will cause the main thread exited flag to be erroneously set when non-main threads complete their work and dispose of thread-specific data. Instead, use the existing `_CFMainPThread` symbol set in `__CFInitialize` to determine the main thread. I am not sure whether the platform `pthread_main_np` is at fault here, but since this workaround makes the tests pass, let's use it.
I'm not sure what happened here. I had a build before this change, but these failed when I tried to build after a clean.
getenv was returning invalid data without it.
It wasn't really accurate. There is some Mach support, but it's incomplete.
|
I think I was probably overly optimistic opening this PR. I've been reading more documentation/code for toll-free bridging to try and figure out how to implement it correctly in a follow-on issue and I'm pretty sure the other frameworks are going to break if this were to get merged. I've found a few locations where frameworks are assuming that they can cast freely between some of the CF and Foundation types. For example, |
|
Good work takes time. Thanks for your persistency |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #82 .
This PR replaces the contents of
Frameworks/CoreFoundationwith the contents of theCoreFoundationsubdirectory for the Swift 5.7.1 release (https://github.com/apple/swift-corelibs-foundation/tree/swift-5.7.1-RELEASE/CoreFoundation).In my fork, I tagged the version corresponding to the unmodified import to serve as a branch point for future updates (https://github.com/deleanor/ravynos/tree/import-swift-cf-swift-5.7-RELEASE).
To see the specific changes to the Swift CF implementation that were required to work with the current RavynOS frameworks, it's probably easiest to view the diff in the
CoreFoundationdirectory against the import tag: eleanxr/ravynos@import-swift-cf-swift-5.7-RELEASE...deleanor:ravynos:swift-cf-RunLoopWithKeventConsiderations:
CFRunLoopmentioned in Swift build on FreeBSD #209 (Omnibus to implement CFRunLoop with kevent. swiftlang/swift-corelibs-foundation#3004).#if TARGET_OS_MAC && !__RAVYNOS__. This is becauseravynos/include/TargetConditionals.hends up definingTARGET_OS_MAC. It may be beneficial to either augment that header to have aTARGET_OS_RAVYNOSor in the longer term make RavynOS fully compatible withTARGET_OS_MAC. For now, we defer to the alternativeTARGET_OS_BSDbranches where necessary by adding a|| __RAVYNOS__where they align.CFRuntimeBase.CoreFoundation.hheader includesCFXMLNode.handCFXMLParser.hwhen the deployment runtime is not Swift, but those files don't exist in the repository as far as I can tell. I conditionally excluded those for now, and I had to excludeCFXMLInterfacefor the same reason. There are versions of those files in Apple's open source CF if we want to try and adapt those later.mainbranch makes it to. I'm not sure what other executables to test, but I'm open to suggestions. I also wrote a simple test forCFRunLoopthat appears to work (https://github.com/deleanor/ravynos-cf-test). I'd love to hear additional suggestions for testing, but short of writing a large test suite to go with this I'm not sure what else I can do in that area at the moment. Future options include using the Foundation test suite that ships withswift-corelibs-foundation, but that would be down the road because it requires Swift language support.