What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
We were using a precondition which crashes the program when invalid input is
provided. We want to provide a way to gracefully check and handle invalid input
or shutdown the program if necessary.
SR-1930
As proposed in SE-0107: UnsafeRawPointer:
Rename 'init(allocatingCapacity:)' to 'UnsafeMutablePointer.allocate(capacity:)'
Rename 'deallocateCapacity' to 'deallocate(capacity:)'
`allocate` should not be an initializer. It's primary function is to allocate
memory, not initialize a pointer.
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 46a9f57329.
This broke Swift CI, OSS incremental RA:
./swift/stdlib/public/SDK/Foundation/TimeZone.swift:228:45: error: 'NSTimeZone' is not implicitly convertible to 'TimeZone'; did you mean to use 'as' to explicitly convert?
return lhs._wrapped.isEqual(to: rhs._wrapped)
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 9c1f21bdf0.
This breaks swift-ci for everyone:
stdlib/public/SDK/Foundation/Calendar.swift:426:74: error: 'DateInterval' is only available on iOS 10.0 or newer
public func dateInterval(of component: Component, for date: Date) -> DateInterval? {
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
Second pass at updates for SE-0086 feedback
<rdar://problem/26892977> Make sure NSOrderedSet keeps its NS
<rdar://problem/26880016> NSBundleResourceRequest should keep its NS
<rdar://problem/26892958> Make sure NSAttributedString keeps its NS
<rdar://problem/26653694> NSCoder.decodeTopLevelObjectForKey does not follow naming guidelines
<rdar://problem/27355801> Foundation should have a structural type for TextCheckingResult
<rdar://problem/26770611> NSExpression naming is a bit awkward in swift
<rdar://problem/26653451> NSCoder encodeDataObject is misleading
<rdar://problem/26653653> NSCoder decodeObjectOfClass is redundant
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
We're now correctly checking for inheritance, adding @objc methods,
and adding @objc protocols for both CF types and objc_runtime_visible
classes (those without visible symbols). The latter is used for some
of the types in Dispatch, which has exposed some of the classes that
were considered implementation details on past OSs.
We still don't properly implement using 'as?' to check conformance to
a Swift protocol for a CF or objc_runtime_visible type, but we can do
that later.
rdar://problem/26850367
...in code that I wrote. The integrated REPL, deprecated though it may
be, does not have an associated DeclContext because its SourceFile is
not considered complete. (The proper LLDB REPL does not suffer from
this problem because they use a new SourceFile for every block of
input.)
Elsewhere, tighten up code that may have hit similar bugs, though we
haven't seen anything hit these yet.
rdar://problem/26476281
Adds an unlabeled rawValue init for swift_newtype(struct), which
expresses the extensibility theme better. This makes the use and
creation of new instances of that type more succinct.
swift_newtype(enum) still requires the explicit label, as it is
non-extensible.
Implement the Objective-C #keyPath expression, which maps a sequence
of @objc property accesses to a key-path suitable for use with
Cocoa[Touch]. The implementation handles @objc properties of types
that are either @objc or can be bridged to Objective-C, including the
collections that work with key-value coding (Array/NSArray,
Dictionary/NSDictionary, Set/NSSet).
Still to come: code completion support and Fix-Its to migrate string
literal keypaths to #keyPath.
Implements the bulk of SR-1237 / rdar://problem/25710611.
Implements almost all of SE-0067. There are a few outstanding features; this implementation does not have:
- formRemainder(dividingBy:)
- formSquareRoot()
- addProduct(_:,_:)
which require additions to the Builtin module. I can probably figure out how to do these, but I haven't had a chance to do so yet. Also missing are the generic initializers and comparisons whose implementation depends on having new Integer protocols.
The last remaining feature of SE-0067 is that while the basic operators +,-,*,/, etc are moved onto the FloatingPoint protocol, they are still required on the concrete types in order to disambiguate overloads. Fixing this seems to require either modifying the overload resolution rules or removing these operators from some other protocols. Or it might just require that someone smarter than me looks at the problem.
Passes the existing tests locally (with the included changes). I'm working on additional tests for the new features.
There are a couple of features that are not yet implemented, because they require additions to the Builtin module. Specifically, this implementation does not have:
- formRemainder(dividingBy:)
- formSquareRoot()
- addProduct(_:,_:)
Also missing are the generic initializers and comparisons whose implementation depends on having new Integer protocols.
The last remaining feature of SE-0067 is that while the basic operators +,-,*,/, etc are moved onto the FloatingPoint protocol, they are still required on the concrete types in order to disambiguate overloads. Fixing this seems to require either modifying the overload resolution rules or removing these operators from some other protocols. Or it might just require that someone smarter than me looks at the problem.
Passes all the existing tests (with the included changes). I'm working on additional tests for the new features.
