Huge thanks to John for noting that 'consume' didn't provide the
guarantees we wanted, and to Michael G. for getting a TSan build up
and running to identify/verify this race.
It's possible that this is overlay strict, and that we only need to
look at the domain to ensure that the code and userInfo are
visible. However, TSan seems to prefix the form in this patch, so
we'll be more conservative for now.
Fixes rdar://problem/27541751.
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.
ArraySlice.removeLast() only worked when startIndex was equal to zero.
This change fixes the bug, and uses the proper customization point for
the algorithm.
Fixes SR-1791, rdar://problem/26897658.
One last bit of SE-0072. We shouldn't fall back to bridged classes in the absence of type context for literals anymore. By itself, this kind of hoses the use of literals with NS types, but I think we can get most of the QoI back with overlay changes I plan to propose following this.
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.
Update for SE-0107: UnsafeRawPointer
This adds a "mutating" initialize to UnsafePointer to make
Immutable -> Mutable conversions explicit.
These are quick fixes to stdlib, overlays, and test cases that are necessary
in order to remove arbitrary UnsafePointer conversions.
Many cases can be expressed better up by reworking the surrounding
code, but we first need a working starting point.
This iterator uses an inline 32-byte buffer so it doesn't have to call
copyBytes(to:count:) for every single byte. It results in an approximate
6x speedup on my computer.
Previously it assumed that if we succeed in looking up the method in the current
module we must be able to request a definition (vs a declaration).
This is not true. It could be that we had declared the type in a different
module. Always ask for a declaration.
rdar://27547957
This iterator uses an inline 32-byte buffer so it doesn't have to call
copyBytes(to:count:) for every single byte. It results in an approximate
6x speedup on my computer.
