> 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 _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
