Improve Error to NSError conversion #2912
Conversation
kgominyuk
force-pushed
the
improve-error-to-nserror-conversion
branch
from
9e27f04 to
7c09116
Compare
|
cc @millenomi |
|
@swift-ci please test |
| XCTAssertEqual((SwiftError.two as NSError).code, 3) | ||
| XCTAssertEqual((SwiftError.three("three") as NSError).code, 0) | ||
| XCTAssertEqual((SwiftError.four as NSError).code, 4) | ||
| XCTAssertEqual((SwiftError.five("five") as NSError).code, 1) |
There was a problem hiding this comment.
It's not quite clear why these values are what they are, especially for those with associated values. Could you add a comment to the test that clarifies this please?
There was a problem hiding this comment.
The test was initially based on actual observed behavior on Darwin platform. In search of details I've found that default error code for enum case is based on enum tag. Tag generation logic is located in EnumImplStrategy::getTagIndex ( https://github.com/apple/swift/blob/d6227dcca01b74b64f078949e69e91324e39f815/lib/IRGen/GenEnum.cpp#L239-L255 ). It starts from cases with payload (.three and .five), and then proceeds to cases without payload (.one , .two , .four ). This is why we are observing such error codes: .three = 0, .five = 1, .one = 2, .two = 3, .four = 4.
There was a problem hiding this comment.
I didn't know that, very interesting behavior. Glad that it could become consistent across platforms.
|
@swift-ci please test |
Error->NSError conversion in Darwin Foundation fills `domain` and `code` even if provided Error does not conform to CustomNSError. This patch brings same behavior to swift-corelibs-foundation.
kgominyuk
force-pushed
the
improve-error-to-nserror-conversion
branch
from
759010e to
9dfb052
Compare
|
@MaxDesiatov Could you please retrigger CI? I squashed commits into one. |
|
@swift-ci please test |
There was a problem hiding this comment.
Seems reasonable to me to preserve the domain and code. I wonder if @millenomi can shed some light on if that was intentionally being dropped here.
|
The only reason we didn't go deep on the first attempt was that we didn't have a lot of infrastructure set up yet and much was deferred to when we'd have good stories for conversion, for localization, etc., which now we do. More compatibility is always a good thing. LGTM |
FoundationTest build on macOS has been broken since swiftlang#2912. Compilation fails with error cannot convert value of type 'SwiftError' to type 'NSError' in coercion. I guess we have to exclude related tests on Darwin platform, but leave them in DarwinCompatibilityTests.
FoundationTest build on macOS has been broken since swiftlang#2912. Compilation fails with error: cannot convert value of type 'SwiftError' to type 'NSError' in coercion. I guess we have to exclude related tests on Darwin platform, but leave them in DarwinCompatibilityTests.
FoundationTest build on macOS has been broken since swiftlang#2912. Compilation fails with error `cannot convert value of type 'SwiftError' to type 'NSError' in coercion`. I guess we have to exclude related tests on Darwin platform, but leave them in DarwinCompatibilityTests.
FoundationTest build on macOS has been broken since swiftlang#2912. Compilation fails with error `cannot convert value of type 'SwiftError' to type 'NSError' in coercion`. I guess we have to exclude related tests on Darwin platform, but leave them in DarwinCompatibilityTests.
Error->NSError conversion in Darwin Foundation fills
domainandcodeeven if provided Error does not conform to CustomNSError. This patch brings same behavior to swift-corelibs-foundation.