Skip to content

Disable toll-free bridging for CFRunLoopTimer #2116

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.

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

Merged
merged 1 commit into from
Apr 17, 2019

Conversation

tokyovigilante
Copy link
Contributor

Foundation.Timer is not currently implemented with a compatible memory layout
so attempt to bridge these classes will fail. Disabling bridging allows
code using CFRunLoopTimer to work until Foundation.Timer is reimplemented.
Fixes https://bugs.swift.org/browse/SR-10465

Copy link
Contributor

@millenomi millenomi left a comment

Choose a reason for hiding this comment

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

Two changes before it's okay.

@@ -4306,7 +4306,7 @@ CFIndex CFRunLoopTimerGetOrder(CFRunLoopTimerRef rlt) {

void CFRunLoopTimerInvalidate(CFRunLoopTimerRef rlt) { /* DOES CALLOUT */
CHECK_FOR_FORK();
CF_OBJC_FUNCDISPATCHV(CFRunLoopTimerGetTypeID(), void, (NSTimer *)rlt, invalidate);
//CF_OBJC_FUNCDISPATCHV(CFRunLoopTimerGetTypeID(), void, (NSTimer *)rlt, invalidate);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please do not disable CF_OBJC_… functions. As the name implies, these are for ObjC (and are no-ops in Swift.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK great, I didn't realise that. Specifically that one however does appear to be casting CFRunLoopTimer to NSTimer *, is that ok to keep in?

@@ -29,7 +29,7 @@ typedef struct CF_BRIDGED_MUTABLE_TYPE(id) __CFRunLoopSource * CFRunLoopSourceRe

typedef struct CF_BRIDGED_MUTABLE_TYPE(id) __CFRunLoopObserver * CFRunLoopObserverRef;

typedef struct CF_BRIDGED_MUTABLE_TYPE(NSTimer) __CFRunLoopTimer * CFRunLoopTimerRef;
typedef struct /*CF_BRIDGED_MUTABLE_TYPE(id)*/ __CFRunLoopTimer * CFRunLoopTimerRef;
Copy link
Contributor

Choose a reason for hiding this comment

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

Please do not disable this. This does not bridge to NSTimer; it bridges to id, meaning that it allows CFRunLoopTimer to be treated as an AnyObject (and thus its API be imported without using Unmanaged<…>.

Copy link
Contributor Author

@tokyovigilante tokyovigilante Apr 16, 2019

Choose a reason for hiding this comment

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

OK makes sense, I did note CFRunLoop itself etc are also CF_BRIDGED_MUTABLE_TYPE there. Should the type remain NSTimer however or be id like the rest?

@millenomi
Copy link
Contributor

In general, changing public API headers is not allowed.

@tokyovigilante
Copy link
Contributor Author

Noted, thanks. Thanks for the feedback!

@tokyovigilante tokyovigilante force-pushed the cfrunlooptimer-unbridged branch from 0904581 to 5a5d730 Compare April 16, 2019 10:20
Foundation.Timer is not currently implemented with a compatible memory layout
so attempt to bridge these classes will fail. Disabling bridging allows
code using CFRunLoopTimer to work until Foundation.Timer is reimplemented.
Fixes https://bugs.swift.org/browse/SR-10465
@tokyovigilante tokyovigilante force-pushed the cfrunlooptimer-unbridged branch from 5a5d730 to af01e68 Compare April 16, 2019 11:48
@tokyovigilante
Copy link
Contributor Author

This one should do it, works on my system without changing the API. Thanks again for the feedback!

@millenomi
Copy link
Contributor

@swift-ci please test and merge

1 similar comment
@millenomi
Copy link
Contributor

@swift-ci please test and merge

@swift-ci swift-ci merged commit 25c881b into swiftlang:master Apr 17, 2019
@tokyovigilante tokyovigilante deleted the cfrunlooptimer-unbridged branch April 17, 2019 01:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants