* replace unused closure parameters with '_' in stdlib source
* fold some _ closure arguments into line above
* fold more _ closure arguments into line above
Apple and the Swift community has settled on this style:
https://devforums.apple.com/message/1133616#1133616
> FWIW, we've recently decided to standardize on () -> Void
> (generally, () for parameters and Void for return types) across all of our
> documentation.
[test] Add a timeout to runRaceTest(). Use it to limit test AtomicInt.swift.
This cuts AtomicInt.swift's execution time from several hours to
about ten minutes on slow hardware and slow build configurations.
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
The new names are what people generally expect. The old names made more
sense in the old times when the 'Optional.None' case could not be
created with the 'nil' keyword.
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
Adds an explicit @escaping throughout the standard library, validation
test suite, and tests. This will be necessary as soon as noescape is
the default for closure parameters.
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.
* [Type System] Handle raw pointer conversion.
As proposed in SE-0107: UnsafeRawPointer.
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#implicit-argument-conversion
UnsafeMutablePointer<T> -> UnsafeMutableRawPointer
UnsafeMutablePointer<T> -> UnsafeRawPointer
UnsafePointer<T> -> UnsafeRawPointer
UnsafeMutableRawPointer -> UnsafeRawPointer
inout:
&anyVar -> UnsafeMutableRawPointer
&anyVar -> UnsafeRawPointer
array -> UnsafeRawPointer
string -> UnsafeRawPointer
varArray -> UnsafeMutableRawPointer
* Rename expectEqual(_, _, sameValue:) to expectEqualTest to workaround a type system bug.
<rdar://26058520> Generic type constraints incorrectly applied to functions with the same name
This is exposed by additions to the type system for UnsafeRawPointer.
Warning: unit tests fail very confusingly without this fix.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
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.
