This initializer, which is the same on iOS, allows negative values and
values > 1.0 to support the extended sRGB color space.
Fixes rdar://problem/33500905.
On initialization, IndexSet.RangeView made the erroneous assumption that given an intersection range, a nil _indexOfRange(containing: bound) indicated that the bound was beyond the beginning or end of the index set. Instead, the index could simply not exist.
We now calculate the actual intersection of the parent index set with the given intersection range and use that as the index set to view.
This also makes the unit tests for testing range views more comprehensive.
When we give NSNumber a custom AnyHashable representation, we want to
give it as large a box as possible. When we want to compare it against
other AnyHashable boxes such as Int or UInt, it's always possible to
upcast the Int/UInt to a larger integer size like Int64 or UInt64 for
the comparison. By eliminating the smaller boxes we create, we can
maintain the existing behavior that _SwiftTypePreservingNSNumber gave
us.
Since samePosition(in:) now unconditionally returns optionals,
String.UTF16View.Index.distance(to: String.UTF16View.Index) must accept an
optional to keep some code working.
Fixes <rdar://33307780>.
By calling through to swift_reportToDebugger, Xcode can pick up the
NSKeyedArchiver/Unarchiver issues with Swift classes and display them
in the Issues Navigator. This increases the probability that they'll
be seen and acted upon.
This is not a fully-general interface yet, please do not start hooking
random things up to it. Especially if you're working on something that
doesn't ship with Xcode itself. :-)
rdar://problem/32900735
{JSON,Plist}{Encoder,Decoder} had overlapping accesses which were supposed to be mutually exclusive in their `with(pushedKey:)` methods.
Removes those methods and the overlapping accesses.
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.
One of the limitations of not having conditional conformance at the
moment is that the implementation of `init(from:)` and `encode(to:)` on
types which require it is that failure to cast dependent types to
`Encodable` or `Decodable` is a runtime failure. There is no way to
statically guarantee that the wrapped type is `Encodable` or
`Decodable`.
As such, in those implementations, at best we can directly call
`(element as! Encodable).encode(to: encoder)`, or similar. However, this
encodes the element directly into an encoder, without giving the encoder
a chance to intercept the type. This is problematic for `JSONEncoder`
because it cannot apply a strategy if it doesn't get to intercept the
type.
This gives a temporary workaround for JSON strategies because of
internal Foundation knowledge.
