[SR-7263] Treat APIs returning unmanaged CF types as NS_RETURNS_INNER…

[ChristopherRogers]

…_POINTER

I've pretty much obeyed the instructions in the bug tracker to the letter, which were pretty straightforward. The only thing I added to that was the optional unwrapping. This is needed to handle when the nullability of the return value is specified as _Nullable or isn't specified, which in this case is very likely. I assumed if it was an Optional multiply nested that it shouldn't behave like NS_RETURNS_INNER_POINTER.

This will make self autoreleased so this may slightly impact the memory footprint of some code.

The bug mentioned (@jrose-apple) getting someone to suggest some test code to add for this. I can add that if still necessary. There was already a test that failed from this change, so maybe that would suffice...? 🤷‍♂️

Resolves SR-7263.

(I've run -r --verification-test on my Mac and everything passes at this point.)

Testing Time: 756.14s
  Expected Passes    : 10858
  Expected Failures  : 26
  Unsupported Tests  : 157
-- check-swift-validation-macosx-x86_64 finished --

[harlanhaskins]

@swift-ci please smoke test

[jrose-apple]

I'm glad this was so straightforward! Yes, I do think it should still have a test—I'd go all the way to making an execution test where the object would be prematurely released otherwise. The basic setup would be a lot like test/Interpreter/SDK/block_globals.swift, with both a .swift file and a .m file to control the behavior on both sides, and we'd want to test what happens in an optimized build. Maybe the Objective-C class that returns the CF type can print something in its -dealloc so we can tell when that final release happens?

Let me know if my scattering of suggestions here isn't enough to go on. Thanks for doing this!

[ChristopherRogers]

I wasn't totally sure where to put the test code so I just put it where I found other test code for returns_inner_pointer stuff. ("Interpreter" didn't make much sense to me.)

[jrose-apple]

Thanks, this looks reasonable to me! Just one comment about the specific object chosen for the test case…

[jrose-apple]

Ah, it's probably best not to use an NSNumber, because those can get uniqued! Maybe an NSMutableString? ("mutable" avoids uniquing there)

[ChristopherRogers]

*slaps forehead* Thanks. I was trying to avoid the tagged pointers thing but this is much simpler.

[jrose-apple]

@swift-ci Please test macOS

[jrose-apple]

@swift-ci Please smoke test Linux

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - eea57a0

[jrose-apple]

preset=buildbot_incremental,tools=RA,stdlib=RA,test=macOS,type=device
@swift-ci Please test with preset

[ChristopherRogers]

Hi, I just wanted to make sure there wasn't anything else I need to do on my end... especially since there was that "build failed" message from swift-ci. Everything's green so I assume it was just a fluke.

[jrose-apple]

Oops! No, just forgot to add this to my list of "things to circle back on once tests pass". Thanks, Christopher!

(I'm still not sure why the preset build didn't work, but I don't foresee any problems regardless.)