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.
Implemented SE-0113 + residual SE-0067 operations.
- adds `rounded` and `round` to `FloatingPoint`, from SE-0113.
- adds `remainder`, `squareRoot`, and `addingProduct`, from SE-0067.
- adds basic test coverage for all of the above.
- provides a default implementation of `nextDown` on `FloatingPoint`.
These apinotes will swift_private many of the bounding box methods,
and adjust the overlays appropriately. Those APIs have better
alternatives provided by the overlays, and thus shouldln't be exposed.
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
The Clang attribute allows one to state that a particular enumeration
type describes an error, and associates it with a particular domain
constant. However, due to lack of API notes support, this attribute
wasn't actually getting used. Instead, we had a number of explicit
extensions to enum types to make them conform to the _BridgedNSError
protocol explicitly.
Now that we have API notes, use them to make these enums into error
enums with the appropriate domain, so that the Clang importer will
synthesize the _BridgedNSError conformances. Then, remove all of the
explicit conformances---and with them, the overlays for 12 frameworks.
There is a small fix to more eagerly consider these conformances as
"used" if an expression is formed with the error enum as a value
type. This better ensures that the conformances will be available at
runtime when needed.
This cleanup is needed to implement SE-0112 (NSError bridging),
although it is useful by itself.
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.
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
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
