The underlying behavior of __SwiftValue bridging now has
a couple of different possible behaviors depending on how
libswiftCore was built and even (in some cases) the specific binary that's
running.
This makes it very hard to craft an accurate test of this functionality.
Disable it (for now) until we can figure out a better way to
conditionalize the expected behavior here.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Github PR #71620 mixed up one of the bincompat conditionals.
It also had some errors in the tests for ObjC interop.
For now, this leaves the legacy behavior in place for
all Apple platforms.
These tests are testing changes that aren't present in older runtimes:
test/stdlib/SwiftValueNSObject.swift
test/stdlib/SwiftObjectNSObject.swift
test/stdlib/BridgeEquatableToObjC.swift
And this test looks for some wording that's different on older runtimes. This one already does availability checks, so we change the requirements to SwiftStdlib 5.11:
test/Casting/CastTraps.swift.gyb
Update PR #68720 with lessons learned in reviewing #69464
Background:
* SwiftValue can expose Swift value types (structs/enums)
to ObjC by wrapping them in an Obj-C object on the heap
* SwiftObject is the Obj-C type that Swift class objects all
inherit from (when viewed from Obj-C). This allows arbitrary
Swift class objects to be passed into Obj-C.
History:
* PR #4124 made Obj-C `-hash` and `-isEqual:` work for SwiftValue for Hashable Swift types
* PR #68720 extended SwiftValue to also support Equatable Swift types
* PR #69464 added similar support to SwiftObject
In the process of working through #69464, we found a better way
to handle an ObjC request for `-hash` for a type that is Swift
Equatable but not Hashable. This PR updates SwiftValue to use
the same approach. The approach considers three cases:
1. A Hashable type can forward both `-hash` and `-isEqual:` to
the Swift object.
2. A type that is neither Equatable nor Hashable can implement
`-isEqual:` as the identity check and `-hash` as returning
the address of the object in memory.
3. A type is that Equatable but not Hashable is more complex.
In this last case, we can easily forward `-isEqual:` to the
Equatable conformance but ObjC also requires us to
always provide a compatible `-hash` implementation.
The only way to do this is to have `-hash` return a constant,
but that is a very bad idea in general, so we're also including
a log message whenever we see a request for `-hash` on
a Swift value that is Equatable but not Hashable.
To limit performance problems from the logging itself, we
emit the log message only once for each type.
