-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Runtime] Add ObjC support to isKnownUniquelyReferenced. #38309
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
Conversation
@swift-ci Please smoke test |
1 similar comment
@swift-ci Please smoke test |
@swift-ci Please clean smoke test |
cd623b6
to
6d58491
Compare
@swift-ci Please clean smoke test |
6d58491
to
aad9abb
Compare
@swift-ci Please smoke test |
aad9abb
to
63054b1
Compare
@swift-ci Please smoke test |
63054b1
to
eb3c316
Compare
@swift-ci Please smoke test macOS platform |
eb3c316
to
ad2ef83
Compare
@swift-ci Please smoke test macOS platform |
@swift-ci Please smoke test |
ad2ef83
to
2ae0da2
Compare
@swift-ci Please smoke test |
2ae0da2
to
f46c75d
Compare
@swift-ci Please smoke test |
A quick glance at the "files changed" view here suggests your indentation settings aren't correct. Perhaps you've set your tabs to be two spaces wide, but you're still inserting tab characters instead of space characters. |
c0d242d
to
5b65c67
Compare
@beccadax Hmmm. I think my editor has picked up the indentation and changed the tab size to match. How annoying. I'll tinker with it. |
@swift-ci Please smoke test |
5b65c67
to
4a69b9d
Compare
@swift-ci Please smoke test |
4a69b9d
to
1146b8b
Compare
@swift-ci Please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Would be good to get a signoff from someone more familiar with IRGen for that part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The IRGen changes LGTM.
I have not audited the standard libraries uses of isUnique to make sure no assumptions are made about the buffer if it returns true i.e it might have checked whether the bridged object is unique and then if that is true assumed that the bridged object pointer points to a native object. We probably always track that separately through the is bridged bit in the pointer to the BridgedObject (_BridgeStorage.isNative
) but I thought to point this out this might be a risk here.
1146b8b
to
d9ae07d
Compare
It's a good point. I had a look through and I don't think there's any problem with this (and all the tests pass too, which is a good sign). Do we have a standard library expert we can ask, just to confirm? |
I think we should audit that all uses are guarded by |
I wonder if there is a performance benefit now from changing the two conditions around in
|
@aschwaighofer Yes, those could be swapped. Also, |
Follow-up is fine by me. |
Hmmm. Looking at this more carefully, |
When the Element type is not a class (or objc existential) then we bridge eagerly (convert the element type at bridging time - no objc storage is used).
|
Add code to support detecting uniquely referenced Objective-C and Core Foundation objects. rdar://47902425 rdar://66805490
d9ae07d
to
abec55f
Compare
@swift-ci Please smoke test |
@swift-ci Please test |
Add code to support detecting uniquely referenced Objective-C and Core Foundation objects.
rdar://47902425
rdar://66805490