The IRGen test had wrong offsets for inline String element on tuples kp on 32-bit platforms
The stdlib test had hardcoded offsets (assumed 64-bit host) for tuple kp elements (Memorylayout)
`\.self` is the final chosen syntax. Implement support for this syntax, and remove the stopgap builtin and `WritableKeyPath._identity` property that were in place before.
Make sure the implementation can handle a key path with zero components by removing inappropriate assumptions that the number of components is always non-empty. Identity key paths also need some special behavior:
- Appending an identity key path should be an identity operation for the other operand
- Identity key paths have a `MemoryLayout.offset(of:)` zero
- Identity key paths interop with KVC as key paths to `@"self"`
To be able to exercise and test this behavior, add a `Builtin.identityKeyPath()` function and `WritableKeyPath._identity` accessor in lieu of finalized syntax.
If a key path refers to inline storage of the root type, this produces the offset in bytes between a pointer to the root and a pointer to the projected storage. Otherwise, returns nil.
When we pre-scan the components of a key path pattern to determine its runtime type and instance size, we would short-circuit upon seeing an optional-chaining component, since that makes a key path definitely read-only, but the loop also accumulates the size of the instance we're supposed to allocate, so…bad stuff happened. Leave out the short-circuit, fixing SR-6096 | rdar://problem/34889333 .
In the type checker, we need to recognize when a member lookup succeeded through an IUO unwrap, and insert the implicit optional-unwrap component into the key path. In the standard library, we need to cope with the fact that IUO is still a first-class type with unique type metadata in a few places. Fix for rdar://problem/33230845.
Using an Array to hold onto all the cleanup objects for an access happens to destroy the cleanup objects in FIFO order (and it's probably not a good idea to rely on Array cleaning itself up in any particular order at all). For want of proper accessor coroutines, chain the cleanup objects in a linked list so that they reliably get destroyed in the desired inside-out order. Fixes SR-5442 | rdar://problem/33267959.
If we project an lvalue using a KeyPath, but the lvalue is only read from, we don't want to trigger writebacks, observers, or other side effects that a mutable projection would normally need to induce. Fixes SR-5338 | rdar://problem/33135489.
Use the KeyPath implementation's new support for instantiating and dealing with captures to lower the generic context required to dispatch computed accessors with dependent generics.
A necessary precursor to supporting subscripts and unspecialized generic accessors in general. Give get/set components the ability to have an "argument" area that gets instantiated by copying out of the key path pattern arguments at instantiation time, and which holds "witness" information for how to copy, destroy, equate, and hash arguments.
This is a bit more robust and user-friendly than hoping more brittle recovery in SILGen or IRGen for unsupported components kicks in. rdar://problem/32200714
A property imported from Objective-C, or marked in Swift with the `dynamic` keyword, doesn't have a vtable slot, so can't be identified that way. Use the ObjC selector as the unique identifier to ascribe equality to such components. Fixes rdar://problem/31768669. (While we're here, throw some more execution tests and a changelog note in.)
I had optimistically written the code here optimistically hoping #7837 would land in time for me to merge, but that didn't happen, so adjust some things to match the current 12-byte object header size on 32-bit, and introduce some ABI constants for the expected 32- and 64-bit object header sizes we can assert against so that we have some robustness when it eventually changes again. Implements rdar://problem/31768303.
With more recent versions of LLVM (e.g., used with master-next) the
argument of REQUIRES is parsed as an expression. Do not use "rdar"
URLS for these since it confuses lit.
