Some feedback / direction on an issue?


(Mark Woollard) #1

Hi

I decided to see if I could contribute and started looking into what seemed it would be a straightforward issue in Foundation framework for Linux. After debugging this led me to conclude it seems to be a more fundamental issue, maybe with the compiler code generation, around exception handling wrt Linux. I’d be interested in some feedback / guidance on this - am happy to take ownership and see where I might get with it but have a lot of learning to do !

The initial issue I looked at was SR-1547 <https://bugs.swift.org/browse/SR-1547> in Foundation but this I determined to be the same issue as SR-585 <https://bugs.swift.org/browse/SR-585>.

I’ve added some comments to these issues relating to my investigation. Anyone have any more insight into this issue or suggestions on where to look next ?

Thanks
Mark


(Joe Groff) #2

The NSError/Swift.Error "toll-free bridging" is a Darwin-only feature, since the Linux port does not support bridging. From the description, it looks like the compiler is still trying to apply the NSError toll-free bridging optimization even on platforms where this is not supported. If I had to guess, I'd say the problem lies here:

https://github.com/apple/swift/blob/master/lib/SIL/SILType.cpp#L461

The `isBridgedErrorClass` function should check whether ObjCInterop is enabled in the LangOpts and unconditionally return false if it is disabled. It would be good to also audit other places we look for NSError subclasses to make sure we're only special casing them in ObjC Interop mode. Thanks for investigating this!

-Joe

···

On Nov 16, 2016, at 10:07 PM, Mark Woollard via swift-dev <swift-dev@swift.org> wrote:

Hi

I decided to see if I could contribute and started looking into what seemed it would be a straightforward issue in Foundation framework for Linux. After debugging this led me to conclude it seems to be a more fundamental issue, maybe with the compiler code generation, around exception handling wrt Linux. I’d be interested in some feedback / guidance on this - am happy to take ownership and see where I might get with it but have a lot of learning to do !

The initial issue I looked at was SR-1547 in Foundation but this I determined to be the same issue as SR-585.

I’ve added some comments to these issues relating to my investigation. Anyone have any more insight into this issue or suggestions on where to look next ?


(Mark Woollard) #3

Joe

Thanks for the pointers, I’ve taken ownership of the issue and will see where I can get with it :slight_smile:

Mark

···

On 17 Nov 2016, at 18:40, Joe Groff <jgroff@apple.com> wrote:

On Nov 16, 2016, at 10:07 PM, Mark Woollard via swift-dev <swift-dev@swift.org> wrote:

Hi

I decided to see if I could contribute and started looking into what seemed it would be a straightforward issue in Foundation framework for Linux. After debugging this led me to conclude it seems to be a more fundamental issue, maybe with the compiler code generation, around exception handling wrt Linux. I’d be interested in some feedback / guidance on this - am happy to take ownership and see where I might get with it but have a lot of learning to do !

The initial issue I looked at was SR-1547 in Foundation but this I determined to be the same issue as SR-585.

I’ve added some comments to these issues relating to my investigation. Anyone have any more insight into this issue or suggestions on where to look next ?

The NSError/Swift.Error "toll-free bridging" is a Darwin-only feature, since the Linux port does not support bridging. From the description, it looks like the compiler is still trying to apply the NSError toll-free bridging optimization even on platforms where this is not supported. If I had to guess, I'd say the problem lies here:

https://github.com/apple/swift/blob/master/lib/SIL/SILType.cpp#L461

The `isBridgedErrorClass` function should check whether ObjCInterop is enabled in the LangOpts and unconditionally return false if it is disabled. It would be good to also audit other places we look for NSError subclasses to make sure we're only special casing them in ObjC Interop mode. Thanks for investigating this!

-Joe