The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
It's not obvious that we can check that hash/equality behavior
is entirely correct, since there are two very different behaviors
which depend on environmental factors that are not easy to test for.
But we can do a quick probe to see whether the current environment
seems to be offering the legacy or non-legacy behavior and then
carefully verify that everything else is consistent with our initial
probe.
This gives us confidence that at least we're not getting inconsistent
behavior.
The layout of a computed key path component carries an argument buffer for captures, which has
the following layout:
```
---
captured values (subscript indices)
---
generic arguments
---
```
When we reference an externally-defined public property or subscript from a key path, and the
external declaration has a property descriptor, then the generic arguments for the external
declaration get appended to the end of this buffer, giving:
```
---
captured values (subscript indices)
---
generic arguments
---
external property's generic arguments
---
```
The convention for key path accessors to bind their generic environment is thus to unpack them
from the end of the argument buffer, so that the external keypath's accessors can find the
arguments to bind the external generic environment while still allowing the enclosing key path
to save the original captured generic environment (which may be necessary to capture the
appropriate conditional and/or retroactive `Equatable` and `Hashable` conformances for
subscript indices).
However, our code generation for binding the generic arguments out of the argument buffer
contained a flawed optimization: for a property, we know there are never any captured values,
so I had assumed that the generic parameters could always be bound from the beginning of the
argument buffer, assuming that the generic parameters make up the totality of the buffer. This
falls over for external property descriptor references when the key path itself captures a
generic environment, since the external property's expected generic environment appears after
the key path's original generic environment. We can fix this by removing the conditional
entirely, and always adjusting the offset we load the generic environment from to look at the
end of the buffer. Fixes rdar://125886333.
This entire suite was copied wholesale from SwiftObjectNSObject.
Some of it may not apply, very little of it has been critically
evaluated. But it should help avoid unexpected changes in SwiftValue behavior.
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.
For an Equatable type, we need a hash implementation that
is compatible with any possible definition of `==`.
Conservatively, that means `-hash` must return a constant.
For non-Equatable types, we know that `==` is identity based,
so we can get better hash behavior by using the object address.
Caveat: This means that non-Equatable types will do two
protocol conformance checks on every call to `hash`.
If a Swift type implements Equatable and/or Hashable and
we then pass that object into ObjC, we want ObjC
`isEqual:` and `hashValue` to use that. This allows
ObjC code to build ObjC collections of Swift objects.
* Support for Hashable struct/enum types was implemented in #4124
* Support for Equatable struct/enum types was implemented in #68720
* This implements support for Hashable and Equatable _class_ types
Caveats:
1. This does a lot of dynamic lookup work for each operation, so is
inherently rather slow. Unlike the struct/enum case, there is no convenient
place to cache the conformance information, so it's not clear that there is a
viable way to make it significantly faster.
2. This is a behavioral change to low-level support code. There is a
risk of breaking code that may be relying on the old behavior.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
Types that have "value semantics" should not have lexical lifetimes.
Value types are not expected to have custom deinits. Are not expected to
expose unsafe interior pointers. And cannot have weak references because
they are structs. Therefore, deinitialization barriers are irrelevant.
rdar://107076869
* Implement String.WordView
* Add isWordAligned bit
* Hide WordView for now (also separate Index type)
add bidirectional conformance
Fix tests
* Address comments from Karoy and Michael
* Remove word view, use index methods
* Address Karoy's comments
aaa
* move all ObjC array tests into a separate file ArraysObjc.swift.gyb
* merge the remaining Arrays.swift.gyb and ArrayNew.swift.gyb files
* move the utilities from ArrayTypesAndHelpers.swift into its only use into ArraysObjc.swift.gyb
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
LLVM doesn't have a stable ABI for Float16 on x86 yet; we're working with Intel to get that fixed, but we don't want to make the type available on macOS until a stable ABI is actually available, because we'd break binaries compiled before any calling convention changes if we do.
Just copy the buffer if it's not unique.
This also implies that if there is a copy-on-write in remove, "shrink" the capacity of the new buffer to the required amount of elements (instead of copying the capacity of the original buffer).
