[SR-7263] Treat APIs returning unmanaged CF types as NS_RETURNS_INNER_POINTER #49811
Assignees
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
compiler
The Swift compiler in itself
good first issue
Good for newcomers
SILGen
Area → compiler: The SIL generation stage
Comments
|
Starter bug instructions: The place where NS_RETURNS_INNER_POINTER is honored is in SILFunctionType.cpp (look for clang::ObjCReturnsInnerPointerAttr). In addition to checking for that attribute, we'd also want to check if the return type in Swift is the Unmanaged struct. You can get the return type from the TypeLowering object, and then see if it's a struct through If someone picks this up, I'll pull in a more SIL-friendly person to suggest a test case to copy from. |
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Attachment: Download
Additional Detail from JIRA
md5: 5e6365a19cffc113eb15c513b965b64c
Issue Description:
When an Objective-C method returns an Unmanaged CF type at +0, there's a delay between when the value is returned and when it ultimately gets retained (by a call to
takeUnretainedValue()).In Objective-C, the Foo instance is guaranteed not to be destroyed until the end of the statement, but Swift has no such rule. However, Objective-C also has a feature called NS_RETURNS_INNER_POINTER, which means that a raw pointer value is only valid as long as the enclosing object lives. We should apply that same behavior for any Unmanaged CF type, with the assumption that it won't affect the lifetime of the object very much because usually the first thing you do with Unmanaged is unpack the value (giving you an actual owning reference to it).
The text was updated successfully, but these errors were encountered: