* [Foundation] Byte access and methods that funnel to byte access for slices of discontiguous data (ala backed by dispatch_data_t) should void heap corruption and walking off the ends of buffers
* add missing parens on test_byte_access_of_discontiguousData
* Use the proper byte count in testing
* [runtime] Clean up symbols in error machinery.
* [runtime] Clean up symbols in Foundation overlay.
* [runtime] Clean up symbols in collections and hashing.
* [runtime] Remove symbol controls from the Linux definition of swift_allocError.
* [tests] Add more stub functions for tests that link directly to the runtime.
...as detected by initializing an individual field without having
initialized the whole object (via `self = value`).
This only applies in pre-Swift-5 mode because the next commit will
treat all cross-module struct initializers as delegating in Swift 5.
When a substring gets bridged to NSString, it loses the initial offset,
therefore APIs that accept or return StringIndex ranges should handle
this case explicitly by adding/subtracting the substring start offset.
Fixes <rdar://problem/33873277>
* 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.
* 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.
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>.
