This ensures that we don't lose information about the NSError when it
is bridged to NSError. Use this to expose information for common keys
in the NSURLError domain (NSURLErrorFailingURLErrorKey,
NSURLErrorFailingURLStringErrorKey,
NSURLErrorFailingURLPeerTrustErrorKey).
This is effectively part of bullet (4) in the proposed solution of
SE-0112, applied to NSURLError. There are a handful of other domains
that need this treatment as well.
NSCocoaError was capturing only the code of a Cocoa error, making it
basically useless. Instead, capture the entire NSError, the code of
which is tracked by an nested, RawRepresentable type Code. Provide
typed accessors for the common keys in the Cocoa error domain, e.g.,
NSFilePathErrorKey, NSStringEncodingErrorKey, NSUnderlyingErrorKey,
and NSURLErrorKey, to make this type easier to use.
This is specifically an implementation of part (4) of the proposed
solution to SE-0112, which makes NSCocoaError more usable. It also
adds localizedDescription to ErrorProtocol.
However, it also introduces the infrastructure needed for importing
error enumeration types more smoothly, e.g., ErrorCodeProtocol
(underscored for now), the ~= operator for matching error codes, and
so on. In essence, NSCocoaError is the pattern that the importer will
follow.
An error type can conform to one or more of these new protocols to
customize its behavior and representation. From an implementation
standpoint, the protocol conformances are used to fill in the
user-info dictionary in NSError to interoperate with the Cocoa
error-handling system.
There are a few outstanding problems with this implementation,
although it is fully functional:
* Population of the userInfo dictionary is currently eager; we
should use user info providers on platforms where they are
available.
* At present, the Swift dynamic casting machinery is unable to unbox a
_SwiftNativeNSError when trying to cast from it to (e.g.) an
existential, which makes it impossible to retrieve the
RecoverableError from the NSError. Instead, just capture the original
error---hey, they're supposed to be value types anyway!---and use that
to implement the entry points for the informal
NSErrorRecoveryAttempting protocol.
This is part (1) of the proposal solution.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
There is no reason for the compiler to be synthesizing a body of
_domain when it can be implemented in a protocol extension. As part of
this, fix a recent regression in the computed domain: it was using
string interpolation, which means that the recent changes not to print
qualified names affected the domain of the generated NSErrors. Oops.
Swift SVN r30343
The case where this comes up is when people name their app and framework
targets the same thing, or when they've renamed their test target module
in an attempt to avoid issues with NSClassFromString and differing
runtime names. We currently do various wrong things when this happens,
so just emit an error instead.
I left a hole for our overlays, which use '@exported import <the-current-module>'
to get at their Clang modules. The previous commit means this can be
replaced by -import-underlying-module, but that doesn't help our tests,
which use -enable-source-import for their overlays. Which we should stop doing.
rdar://problem/21254367
Swift SVN r29440
The Cocoa error domain is comprised on error codes from Foundation,
CoreData, and AppKit. Rather than try to collect all of the error
codes into a single enum in Foundation, use a struct that conforms to
ErrorType. Part of rdar://problem/20536610.
Swift SVN r28755
More of rdar://problem/20536610. _POSIXError is underscored because
this work needs to go to API review still.
Now with a proper build condition for _POSIXError on Darwin.
Swift SVN r28625
Fix the script to not wantonly drop availability annotations, and
update NSCocoError accordingly. Also drop in a reinterpret-casting
rawValue initializer, which matches what we get when importing enums
from C.
Swift SVN r28563
Bridging the Cocoa error domain requires us to gather constants from
Foundation, CoreData, and AppKit, then pulling those into a single
(_)NSCocoaError enum that conforms to
_ObjectiveCBridgeableErrorType.
Rather than using a table extracted from the appropriate Cocoa headers
and pushing that through gyb, just hardcode the resuting Swift code,
which is produced (manually) by an enumeration-parsing script. Thanks
to Dave for pointing out that I was holding gyb wrong.
... and apologies for the Perl.
Long term, we need a better solution here, but this will suffice for
the short term.
Swift SVN r28560
