[Typechecker] Allow bridging of Unmanaged to Objective-C for throwing functions

[theblixguy]

Previously, we would emit an error diagnostic if a throwing @objc function returned Unmanaged<T>. This is now allowed when T is representable in Objective-C.

For example:

class Foo {}

@objc protocol Bar {
  func throwingMethod1() throws -> Unmanaged<CFArray> // ok
  func throwingMethod2() throws -> Unmanaged<Foo> // error
}

Resolves SR-9035.

[theblixguy]

cc @jrose-apple

[jrose-apple]

Thanks for picking this up! I'm worried that we won't necessarily compile this correctly, though, so can you add an execution test where a Swift thing is being called from Objective-C and the Objective-C side handles both the success and failure cases?

[jrose-apple]

(Alternately, an IRGen test, but only if you want to practice writing IRGen tests.)

[jrose-apple]

Thanks! I have a bunch of FileCheck tips now on how to make this test more robust.

[theblixguy]

Thanks Jordan, I have updated the test file with your suggestions.

[jrose-apple]

Heh, okay. More semantic names are nicer for maintainers, but this is good enough to run tests! …except for the return type thing.

[jrose-apple]

@swift-ci Please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 2019567576b2f5aebbba9e7ebfa8202679d9bbd1

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 2019567576b2f5aebbba9e7ebfa8202679d9bbd1

[theblixguy]

Hmm fails on iOS simulator:

/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/swift/test/IRGen/unmanaged_objc_throw_func.swift:10:17: error: CHECK-LABEL: expected string not found in input
18:58:50 // CHECK-LABEL: define hidden swiftcc %TSo10CFArrayRefa* @"$s25unmanaged_objc_throw_func9SR_9035_CC22returnUnmanagedCFArrays0G0VySo0H3RefaGyKF"(%T25unmanaged_objc_throw_func9SR_9035_CC* swiftself, %swift.error** noalias nocapture swifterror dereferenceable(8)) #{{[0-9]+}} {
18:58:50                 ^
18:58:50 <stdin>:1:1: note: scanning from here
18:58:50 ; ModuleID = '-'
18:58:50 ^

I guess we don't emit define on the simulator? could also just remove the entire CHECK-LABEL as it's not important what this function is called.

[jrose-apple]

It matters which function it is, though. I suspect the difference is going to be in all those attributes of the error parameter…at the very least the pointer size is different. It's probably worth testing locally with a 32-bit simulator (watchOS is easiest to get working) to see where else the CHECK lines are assuming pointer sizes!

[jrose-apple]

This turned out to be a lot more than I thought it would be.

[theblixguy]

How do I test with a simulator? Is it just a matter of adding “REQUIRES: ios” to the test file or is there a special flag I need to pass to the build script?

[jrose-apple]

Ah, check out docs/Testing.md and the sample lit.py invocation. The test directory you pick determines which target you're testing.

[theblixguy]

Sorry for the delay. lit didn't work for me, but I was able to get the test running on the watchOS simulator using cmake.

So basically, we have a bunch of i64s and on 32-bit devices, we want to ensure they're i32s instead, so I have added a pattern to do that. Same with align (sometimes we have align 4, sometimes align 8).

Additionally, the CHECK-LABEL was failing because the string didn't contain swifterror. I have added a pattern to make it optional, however it's not working. Is there something wrong with the pattern {{(swifterror)?}}? It should work as it's valid regex. This only happens on the watchOS simulator - I tried running the tests on macOS and it passed as expected.

[jrose-apple]

I think we don't have a special swifterror convention on 32-bit platforms either. Something like that.

@swift-ci Please test

[theblixguy]

Oh! Seems like the macOS test just disappeared!

Anyway, if it fails then we either need add “REQUIRES: CPU=x86_64” and just not run this on 32-bit or add a “CHECK-LABEL” for each architecture (CHECK-LABEL-i386, etc).

[jrose-apple]

Hrm.

@swift-ci Please test macOS

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - a1ffae5

[jrose-apple]

I suggest cutting down the CHECK-LABEL line to just match the full name of the function. That should be sufficiently unique, and it's not likely that the parameters are being emitted wrong.

CHECK-LABEL: define hidden swiftcc %TSo10CFArrayRefa* @"$s25unmanaged_objc_throw_func9SR_9035_CC22returnUnmanagedCFArrays0G0VySo0H3RefaGyKF"

[theblixguy]

Yeah, I've done that now!

[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 - 8bdc916

[theblixguy]

Tests have passed! Can I cherry-pick this to 5.1?

[jrose-apple]

This is a pretty contained change, and it only enables more code than before. Yes, I think that's okay!