A given Objective-C error enum, which is effectively an NS_ENUM that
specifies its corresponding error domain, will now be mapped to an
ErrorProtocol-conforming struct that wraps an NSError, much like
NSCocoaError does. The actual enum is mapped to a nested "Code"
enum. For example, CoreLocation's CLError becomes:
struct CLError : ErrorProtocol {
let _nsError: NSError
// ...
@objc enum Code : Int {
case ...
}
}
This implements bullet (2) in the proposed solution of SE-0112, so
that Cocoa error types are mapped into structures that maintain the
underlying NSError to allow more information to be extracted from it.
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.
Concurrently with the development of struct IndexSet, the stdlib team
was busy reworking the way that all indexes in collections worked
(https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md).
Both efforts landed at basically the same time. We did the minimum
possible to adopt the new indexing model when IndexSet landed. This
change more correctly adopts the new model.
In summary, the new model has the Collection change the value of the
Index, instead of the Index changing the value on its own. Previously,
the Index had methods like successor(), but now the Collection has
methods like index(after:). This means that the index no longer has to
store a reference to the collection in many cases, which means that CoW
semantics can kick in far more often as the index is a dead simple model
object that just stores a bunch of integers. So basically, this change
moves all the logic for moving indexes from Index into IndexSet.
<rdar://problem/26269319> More fully adopt new indexing model for better performance in IndexSet
The Swift 3 refactoring of the range type has led to its split into 4
different types. The IndexSet API should accept any of these as long as
they contain the element type (Int, which is inherently Countable). This
allows callers to use both the ... and ..< syntax, for example.
This commit also adds additional unit tests for some of the IndexSet
API, and turns a few methods with optional/default args into properties
or a method family, since otherwise callers would end up with an
ambigious method call as the range argument would have been defaulted to
nil.
<rdar://problem/26532614> Add overloads for range types to IndexSet
Due to current language limitations (26607639), MeasurementFormatter's
stringFromMeasurement: is esentially useless when imported into Swift.
This workaround allows it to work as expected.
<rdar://problem/27173952> Workaround: MeasurementFormatter.string(from:
Measurement<Unit>) doesn't recognize subclasses of Unit
Addresses the following issues:
rdar://problem/25992816 -[NSUserDefaults registerDefaults] is being imported as NSUserDefaults.register(), which is confusing
rdar://problem/26291437 UserDefaults has 'setURL(forKey:)' instead of 'set(_:forKey:)'
rdar://problem/26375229 FileManager overlay has old naming
rdar://problem/26090891 NSBundle methods that are overridden in the apinotes incorrectly handle the first argument pattern
rdar://problem/26271340 struct URL initializer for fileURLWithFileSystemRepresentation is incorrectly named'
rdar://problem/26443640 XMLDTDNode.Kind conflicts with XMLNode.Kind and should be renamed to XMLDTDNode.DTDKind
rdar://problem/26500390 registerUndoWithTarget in overlay not updated for new API names
rdar://problem/26653451 NSCoder encodeDataObject is misleading
rdar://problem/26653653 NSCoder decodeObjectOfClass is redundant
rdar://problem/26653694 NSCoder.decodeTopLevelObjectForKey does not follow naming guidelines
rdar://problem/26656299 SocketNativeHandle should be a hoisted type to SocketPort
https://bugs.swift.org/browse/SR-1903
This removes the `_core` property from UnicodeScalarView.Index
and moves any remaining index-moving logic from the index to
the view in UnicodeScalarView and CharacterView.
addresses:
rdar://problem/26385078 Data() really needs a init(length:) and replaceBytes(in:withBytes:)
rdar://problem/26508250 Add more specific init method to Data to indicate keeping a ref type
Some mutation cases will cause the underlying copy on write cases to crash with a _SwiftNSCharacterSet doesn't respond to -mutableCopyWithZone: failure.
Fixes Bugs:
https://bugs.swift.org/browse/SR-1782
<rdar://problem/26608216>
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
Initialising with a base64 encoded string was using Base64EncodingOptions rather than Base64DecodingOptions - this means strings with unknown characters cannot be decoded properly as the .ignoreUnknownCharacters option is unavailable
