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
semantically unambiguous.
We didn't actually intend to change how programmers normally
constructed these types, but the change to the object literal
syntax accidentally caused these initializers to have very
natural-seeming signatures. These initializers also created
possible ambiguities with the actual initializers. Renaming
them to refer to their function as literal initializers is the
right thing to do.
Unfortunately, this provided to be somewhat annoying, as the
code was written to assume that the argument tuple following
e.g. #colorLiteral could be directly passed to the initializer.
We solve this by hacking on both ends of the constraint system:
during generation we form a conversion constraint to the
original, idealized parameter type, and during application we
rewrite the argument tuple type to use the actual labels.
This nicely limits the additional complexity to just the
parts dealing with object literals.
Note that we can't just implicitly rewrite the tuple expression
because that would break invariants tying the labels to physical
source ranges. We also don't want to just change the literal
syntax again and break compatibility with existing uses.
rdar://26148507
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
It should have the same form as the argument to NS_SWIFT_NAME
in Objective-C, except that it permits operators and (currently)
disallows instance members and properties. We do get to share the
same parsing code, at least.
This actually caught an error in the Foundation overlay!
Groundwork for SR-1008.
* Implement the majority of parsing support for SE-0039.
* Parse old object literals names using new syntax and provide FixIt.
For example, parse "#Image(imageLiteral:...)" and provide a FixIt to
change it to "#imageLiteral(resourceName:...)". Now we see something like:
test.swift:4:9: error: '#Image' has been renamed to '#imageLiteral
var y = #Image(imageLiteral: "image.jpg")
^~~~~~ ~~~~~~~~~~~~
#imageLiteral resourceName
Handling the old syntax, and providing a FixIt for that, will be handled in a separate
commit.
Needs tests. Will be provided in later commit once full parsing support is done.
* Add back pieces of syntax map for object literals.
* Add parsing support for old object literal syntax.
... and provide fixits to new syntax.
Full tests to come in later commit.
* Improve parsing of invalid object literals with old syntax.
* Do not include bracket in code completion results.
* Remove defunct code in SyntaxModel.
* Add tests for migration fixits.
* Add literals to code completion overload tests.
@akyrtzi told me this should be fine.
* Clean up response tests not to include full paths.
* Further adjust offsets.
* Mark initializer for _ColorLiteralConvertible in UIKit as @nonobjc.
* Put attribute in the correct place.
