Fixes the Android build, and makes some adjustments for Android NDK r13.
* Fix FindICU.cmake to properly set the `SWIFT_${sdk}_ICU_UC` and
`SWIFT_${sdk}_ICU_I18N` values. These were not properly set because
"uc" and "i18n" were lowercase.
* Adapt `add_swift_library` to parse `ICU_UC` and `ICU_I18N` for
private link libraries and use the proper `SWIFT_${sdk}_ICU_*` values.
* NDK r13 removes a subdirectory from the llvm-libc++ includes path.
Adapt to this change, and add a FIXME to address this issue before it
may break again.
* Update the documentation to point to a new libicu download for NDK 13.
* [stdlib] Fix String.UTF16View index sharing
* [stdlib] Fix String.UnicodeScalarView index sharing
* [stdlib] Fix String.CharacterView index sharing
* [stdlib] Test advancing string indices past their ends
* [stdlib] Simplify CharacterView ranged subscript
Now that we have the ability to write extensions where one of the type
parameters is equivalent to a concrete type, eliminate
_AnyHashableProtocol and provide AnyHashable-specific behavior for
Dictionary (where Key == AnyHashable) and Set (where Element ==
AnyHashable) rather than employing the "Key: _AnyHashableProtocol"
hack.
Fixes standard library ABI FIXME's #35, #37, #39.
The "mutating" keyword should not have been on this API. The example
code in SE-0138 uses it as a nonmutating API.
(The mutating keyword was a temporary workaround that should never
have been carried over to the swift-3.0-branch).
<rdar://28614519> [swift-3.0-branch] Remove "mutating" keyword from Array.withUnsafeBytes
... instead of ManagedBufferPointer.
This is what we already did for Array, Set and Dictionary.
The intention is to simplify the generated SIL which is generated for ManagedBuffer operations.
A recent change made accessibility checking stricter. This had some
fallout on the half-baked @_versioned attribute, where we could no
longer define @_versioned members on a non-@_versioned type.
This was wrong anyway (and will be diagnosed when we add proper
diagnostics for @_versioned), because type metadata for the
internal type did not get the right linkage, but it used to work
as long as you didn't try to get the type metadata at runtime.
This patch adds @_versioned attributes to the right types now that
this broken behavior is gone.
As a result, _Variant{Set,Dictionary}Storage became resilient
(non-@_versioned internal types are not resilient), which broke
too many tests that assumed you can exhaustively switch over all
the cases. Since eager-bridging is going to eliminate this enum
anyway (or so I've heard), make it @_fixed_layout for now.
The result of these methods was incorrectly documented as having
the same sign as `other` (the divisor) rather than `self` (the
dividend). This patch corrects the documentation, and also fixes
the capitalization of `formTruncatingRemainder` in one location.
https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md
Unsafe[Mutable]RawBufferPointer is a non-owning view over a region of memory as
a Collection of bytes independent of the type of values held in that
memory. Each 8-bit byte in memory is viewed as a `UInt8` value.
Reads and writes on memory via `Unsafe[Mutable]RawBufferPointer` are untyped
operations. Accessing this Collection's bytes does not bind the
underlying memory to `UInt8`. The underlying memory must be bound
to some trivial type whenever it is accessed via a typed operation.
In addition to the `Collection` interface, the following methods from
`Unsafe[Mutable]RawPointer`'s interface to raw memory are
provided with debug mode bounds checks: `load(fromByteOffset:as:)`,
`storeBytes(of:toByteOffset:as:)`, and `copyBytes(from:count:)`.
This is only a view into memory and does not own the memory. Copying a value of
type `UnsafeMutableRawBufferPointer` does not copy the underlying
memory. Assigning an `Unsafe[Mutable]RawBufferPointer` into a value-based
collection, such as `[UInt8]` copies bytes out of memory. Assigning into a
subscript range of UnsafeMutableRawBufferPointer copies into memory.
Swift value types are their bridged Objective-C classes can have
different hash values. To address this, AnyHashable's responds to the
_HasCustomAnyHashableRepresentation protocol, which bridge objects of
those class types---NSString, NSNumber, etc---into their Swift
counterparts. That way, we get consistent (Swift) hashing behavior
across platforms.
However, there are cases where multiple Swift value types map to the
same Objective-C class type. In such cases, AnyHashable ends up
converting the object of class type back to some canonical type. For
example, an NS_STRING_ENUM (such as (NS)RunLoopMode) is a Swift
wrapper around a String. If an (NS)RunLoopMode is placed into an
AnyHashable, it maintains it's Swift type identity (which is correct
behavior). If it is bridged to Objective-C, it becomes an NSString; if
that NSString is placed into an AnyHashable, it produces a String. The
hash values still line up, but equality of the AnyHashable values
fails, which breaks when (for example) a dictionary with AnyHashable
keys is used from Objective-C. See SR-2648 / rdar://problem/27992351
for a case where this breaks interoperability.
To address this problem, make AnyHashable's casting and equality
sensitive to the origin of the hashed value: if the AnyHashable was
created through a _HasCustomAnyHashableRepresentation conformance,
treat comparisons/casting from it as "fuzzy":
* For equality, if one of the AnyHashable's comes from a custom
representation (e.g., it originated with an Objective-C type like
NSString) but the other did not, bridge the value of the *other*
AnyHashable to Objective-C, re-wrap it in an AnyHashable, and
compare that. This allows, e.g., an (NS)RunLoopMode created in Swift
to compare to an NSString constant with the same string value.
* For casting, if the AnyHashable we're casting from came from a
custom representation and the cast would fail, bridge to Objective-C
and then initiate the cast again. This allows an NSString to be
casted to (NS)RunLoopMode.
Fixes SR-2648 / rdar://problem/27992351.
