* Mutations of slices of data should preserve relative indexing as well as cow semantics of slices
* Ensure hashes of ranges are uniform to the expected hash for Data
* Correct a few mistakes in the slice mutation tests
* Update sequence initializations to avoid directly calling mutableCopy which prevents slice offset mismatches
* Avoid invalid index slices in creating mirrors
* Restore the original Data description
* Resetting a slice region should expand the slice to the maximum of the region (not a out of bounds index of the backing buffer)
* Remove stray comment and use a stack buffer for sequence appending
* Return false when allocations fail in _resizeConditionalAllocationBuffer (not yet in use)
* Enumeration of regions of a slice should be limited to the slice range in the case of custom backing (e.g. dispatch_data_t)
* adjust assertion warnings for data indexes that are negative
JSONEncoder and PropertyListEncoder both use NSNumber to box Bool values. An encoded Bool can be coerced to any numerical type during decoding because (false as NSNumber).intValue == 0. As a remedy, all of the unbox(_:as:) methods of _JSONDecoder and _PlistDecoder for numerical types include a check that the value is not identical to either kCFBooleanTrue or kCFBooleanFalse, and throw a DecodingError._typeMismatch(at:expectation:) if this check fails.
Multiple overlays depend on ModelIO transitively, inlcuding GLKit. So an
app linked against GLKit will successfully build and run on the modern
OSes, but will crash on load if back-deployed to an OS where ModelIO did
not exist.
<rdar://problem/33960842>
<rdar://problem/33471433>
(cherry picked from commit 1c385f189c)
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
At the top level, JSONEncoder/PropertyListEncoder (and the decoders) directly encoded values into an encoder instead of following the logic to box the values (and thus dispatch based on the type, potentially intercepting representations or applying strategies). This led to top-level values having a different representation than similar values throughout a payload.
As a temporary workaround for SR-5206, certain Foundation types which had custom behavior in JSONEncoder and JSONDecoder were granted special knowledge of those types internally in order to preserve strategies on encode/decode.
This replaces that special knowledge with a more general-purpose fix that works for all types and all encoders/decoders.
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
