Include the initial implementation of _StringGuts, a 2-word
replacement for _LegacyStringCore. 64-bit Darwin supported, 32-bit and
Linux support in subsequent commits.
- Revise Equatable and Hashable for synthesized requirements
- Complete Strideable and stride(from:...:by:) documentation
- Revise DoubleWidth type docs
- Add complexity notes for Set.index(of:) and .contains(_:)
- Fix typos in Set.formUnion docs
- Add missing axioms for SetAlgebra (SR-6319)
- Improve guidance for description and debugDescription
- Add note about the result of passing duplicate keys to
Dictionary(uniqueKeysWithValues:)
- Fix typo in BinaryInteger docs
- Update Substring docs with better conversion example
- Improve docs for withMemoryRebound and isKnownUniquelyReferenced
- Add missing docs not propagated from protocols
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
I failed to merge the upstream changes to swift-corelibs-foundation at the same
time as I merged that #9806, and it broke on linux. Going to get it right this
time.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
It is still possible to get the same behavior by providing an explicit
type context, or in a generic code, but otherwise, `String("")!` will
not compile.
* [stdlib] Backward compatibility fix for a flatMap on [String]
Since String started to conform to Collection, the flatMap with a
sequence returning closure is now a better match that the one that
relies on the optional promotion in this code:
[""].flatMap { $0 }
which results in the default type of this expression changing from
[String] to [Character].
Restoring the old behavior in Swift 3 mode by adding a very explicit
overload.
Fixes: <rdar://problem/32024978>
* [stdlib] Fixing another compatibility issue with [String].flatMap
* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
* [stdlib] String : RangeReplaceableCollection & BidirectionalCollection
* Add source compatibility hack for Swift.max
* Add source compatibility hack for Swift.min
* Remove redundant conformance in benchmarks
* Fix stupid typo I thought I'd already pushed
* XFAIL testing now-redundant conformance
* XFAIL an IDE test for now
In various cases where we had global operators for non-generic
concrete types (such as String + String), move those operators into
the type. This should not affect the sources, but makes the exposition
of the library cleaner.
Plus, it's a good test for the compiler, which uncovered a few issues
where the compiler was coupled with the library.
