-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[PrintAsObjC] Use 'unsafe_unretained' to print 'unowned', not 'assign' #19167
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
[PrintAsObjC] Use 'unsafe_unretained' to print 'unowned', not 'assign' #19167
Conversation
@swift-ci Please test source compatibility |
@swift-ci Please smoke test Linux |
@swift-ci Please test macOS |
lib/PrintAsObjC/PrintAsObjC.cpp
Outdated
// We treat "unowned" as "unsafe_unretained" (even though it's more like | ||
// "safe_unretained") because we want people to think twice about | ||
// allowing that object to disappear. "unowned(unsafe)" (and Unmanaged, | ||
// handled below) really are "unsafe_unretained". |
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.
Can this reasonably be turned into an exhaustive switch over reference storage kinds?
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.
Comment aside, LGTM. I filed rdar://44290715 before I caught up on my code-review inbox and saw that you'd done work on this, though, sorry.
The ObjC generator previously preserved a subtle difference between 'unowned' and 'unowned(unsafe)' / Unmanaged by printing the former as 'assign' and the latter as 'unsafe_unretained'. Upstream Clang, however, has gotten a new warning to discourage the use of 'assign' with reference-countable types at all. Since it was always a subtle distinction, just go with the new convention and print 'unsafe_unretained' for 'unowned' properties as well. rdar://problem/44290715
Exhaustively switch over reference types, so that we'll know if any new ones are added, and factor out a repeated check to see if something's a retainable object type. No functionality change.
a0e711b
to
340090c
Compare
Good suggestion, spotted another reasonable cleanup while I was doing that. @swift-ci Please smoke test |
…type The issue was fixed in #19167 so we no longer need to disable this warning. rdar://problem/47777548
…type The issue was fixed in #19167 so we no longer need to disable this warning. rdar://problem/47777548
…type The issue was fixed in #19167 so we no longer need to disable this warning. rdar://problem/47777548
The ObjC generator previously preserved a subtle difference between
unowned
andunowned(unsafe)
/ Unmanaged by printing the former asassign
and the latter asunsafe_unretained
. Upstream Clang, however, has gotten a new warning to discourage the use ofassign
with reference-countable types at all. Since it was always a subtle distinction, just go with the new convention and printunsafe_unretained
forunowned
properties as well.rdar://problem/44290715