...to remove the temptation to put everything in one file with the same
name as the module. This doesn't do anything for overlays that /already/
have everything in one file with the same name as the module, except for
a few easy cases; we can unpack the rest later.
os/activity.h or os/log.h. Update cmake files again, hardcoding a Darwin
dependency. The script does not notice that Foundation depends on
CoreGraphics, so add that manually.
Also found that MapKit is supported on WATCHOS but we didn't have dependencies
for that.
Favor one line per supported SDK instead of catch-all dependency lines.
Distinguish from SDKs which have no dependencies vs SDKs which are
unsupported on a particular platform by printing `unsupported` to the
console and remove the line in the cmake file because it should
not exist anyway.
This full cleanup was not done before because of circularity detected by the
util, which has since been fixed.
Support directories with spaces.
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.
The problem here is a bit complicated. The symlink_clang_headers target creates two symlinks to clang's headers, one under the build directory at lib/swift/clang, and the other under a temporary path.
The one under the temporary path is a bad symlink, and it is only created during the build so that it can be installed. It isn't actually used by the build. Ninja treats the bad symlink as a non-existing file, and since the build rule that creates it has the restat property on it this results in the commands to symlink the clang headers directory running over and over and over again during the build.
This patch prevents that by not generating the bad symlink during the build. Instead we generate it at install time using the LLVMInstallSymlink script that is vended as part of LLVM's distribution.
added the build breaks. There's already a tool to get proper
dependencies, `utils/find-overlay-dependencies.sh`, so this patch
allows that tool to update the `CMakeLists.txt` files in-place.
Also it adds a line to the `CMakeLists.txt` files for each SDK so that the tool works.
The `add_swift_library` CMake function takes an optional `TARGET_SDKS`
parameter. When used, only CMake targets for the specified SDKs are added.
Refactor `stdlib/public/runtime` to use this parameter. This also eliminates
logic that determines additional flags or source files to include based on
`SWIFT_HOST_VARIANT`, which makes it easier for hosts to add targets for
different platforms.
Previously we would crash if we couldn't look up an associated
type witness for a concrete type.
Instead, propagate the failure up to type lowering, which returns
nullptr to the caller, just like when other metadata is missing.
Clang importer is unable to handle `((void *)-1)`, therefore manually
declaring the said constant in both Darwin and Glibc modules.
rdar://problem/26689135
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.
Extend NSNumber bridging to cover not only `Int`, `UInt`, `Double`, and `Bool`, but all of the standard types as well. Extend the `TypePreservingNSNumber` subclass to accommodate all of these types, so that we preserve type identity for `AnyHashable` and dynamic casting of Swift-bridged NSNumbers. If a pure Cocoa NSNumber is cast, just trust that the user knows what they're doing.
This XFAILs a couple of serialization tests that attempt to build the Foundation overlay, but which don't properly handle `gyb` files.
While here, fix up the type signature of
CKError.partialErrorsByItemID; it doesn't make sense to use NSObject
now that we have AnyHashable. Fixes rdar://problem/27936562.
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.
For every struct type for which the frameworks provides an NSValue category for boxing and unboxing values of that type, provide an _ObjectiveCBridgeable conformance in the Swift overlay that bridges that struct to NSValue, allowing the structs to be used naturally with id-as-Any APIs and Cocoa container classes. This is mostly a matter of gyb-ing out boilerplate using `NSValue.init(bytes:objCType:)` to construct the instance, `NSValue.objCType` to check its type when casting, and `NSValue.getValue(_:)` to extract the unboxed value, though there are a number of special snowflake cases that need special accommodation:
- To maintain proper layering, CoreGraphics structs need to be bridged in the Foundation overlay.
- AVFoundation provides the NSValue boxing categories for structs owned by CoreMedia, but it does so using its own internal subclasses of NSValue, and these subclasses do not interop properly with the standard `NSValue` subclasses instantiated by Foundation. To do the right thing, we therefore have to let AVFoundation provide the bridging implementation for the CoreMedia types, and we have to use its category methods to do so.
- SceneKit provides NSValue categories to box and unbox SCNVector3, SCNVector4, and SCNMatrix4; however, the methods it provides do so in an unusual way. SCNVector3 and SCNVector4 are packaged into `CGRect`s and then the CGRect is boxed using `valueWithCGRect:`. SCNMatrix4 is copied into a CATransform3D, which is then boxed using `valueWithCATransform3D:` from CoreAnimation. To be consistent with what SceneKit does, use its category methods for these types as well, and when casting, check the type against the type encoding SceneKit uses rather than the type encoding of the expected type.
SE-0107 states that UnsafePointer.withMemoryRebound(to:capacity:) should produce
a const UnsafePointer, but the implementation that I committed in Whitney
produces an UnsafeMutablePointer.
As a result Swift 3 accepts code, that we would like to reject:
func takesUInt(_: UnsafeMutablePointer<UInt>) {}
func takesConstUInt(_: UnsafePointer<UInt>) {}
func foo(p: UnsafePointer<Int>) {
p.withMemoryRebound(to: UInt.self, capacity: 1) {
takesUInt($0) // <========= implicitly converts to a mutable pointer
takesConstUInt($0)
}
}
We would like to reject this in favor of:
func takesUInt(_: UnsafeMutablePointer<UInt>) {}
func takesConstUInt(_: UnsafePointer<UInt>) {}
func foo(p: UnsafePointer<Int>) {
p.withMemoryRebound(to: UInt.self, capacity: 1) {
takesUInt(UnsafeMutablePointer(mutating: $0))
takesConstUInt($0)
}
}
This looks to me like an experimental change accidentally creeped onto my branch
and it was hard to spot in .gyb code. I needed to write the unit test
in terms of UnsafeMutablePointer in order to use expectType, so didn't
catch this.
rdar://28409842 UnsafePointer.withMemoryRebound(to:capacity:) incorrectly produces a mutable pointer argument
