Replacing the old key with the new is unnecessary and somewhat surprising. It is also harmful to some usecases.
rdar://problem/32144087
# Conflicts:
# stdlib/public/core/NativeDictionary.swift
Affected operations:
subscript(index:)
keys.subscript(index:)
values.subscript(index:) (setter and _modify)
remove(at:)
swapAt(_:, _:)
Note that index(after:) is intentionally not on this list.
Like before, allow the use of Cocoa indices to access native sets/dictionaries, but approximate the same mutation count-based check as we do for native indices.
- Ensure that native collections that were converted from Cocoa have an age generated from the address of the original Cocoa object.
- To get the age of a Cocoa index, regenerate one from the object embedded in it.
- Compare self.age to index.age and trap if it doesn’t match.
# Conflicts:
# stdlib/public/core/HashTable.swift
Native sets and (especially!) native dictionaries must support indexing with Cocoa indices — indices must be preserved when a Cocoa set/dictionary is converted to native.
This is especially the case for Dictionaries that were converted because of a mutation restricted to values — such as those done through the Values view.
The mutation count will allow us to recognize and trap on invalid indices more reliably. (However, it won’t be foolproof — some invalid indices may pass through the checks.)
- Change _scale to Int8 to make space for an extra Int32 without enlarging the storage header.
- Add an _age field inside the new gap.
- Initialize the age to a scrambled version of the storage address.
- Generate a new counter for every newly allocated storage instance, except for identical copy-on-write copies.
- Increment the mutation counter after every removal.
- Remove the old Index typealias for _HashTable.Bucket
- Rename _HashTable.AgedIndex to _HashTable.Index
- Rename _HashTable.Bucket.bucket to _HashTable.Bucket.offset
- Rename/update _HashTable members to adopt to new terminology
At the moment the location being reported is inside the standard
library, which is not very helpful. Instead, the location should point
at the `try!` expression in the application code.
Fixes: rdar://problem/21407683
