The removal of these operator declarations caused a source
compatibility break, because some Swift code is defining prefix or
postfix ++/-- functions without defining the ++ or --
operators. Reinstate the operator declarations in the standard
library... but not any of the functions.
Fixes rdar://problem/43258773.
* Removing FIXME from methods also marked always/never
* Unavailable/deprecated things don't need inlining
* Trivial implementations
* Enum namespaces
* Unsafe performance of opaque/raw pointer
* Dump doesn't need to be fast
* Error paths shouldn't require inlining
* Consistency with surrounding code
* Lazy performance needs specialization
Otherwise, the textual interface won't see them, and any inlinable
code that wants to make use of the protocol might get confused.
We should have a check for this in the compiler itself, but for now
I'm just providing this change to get unblocked.
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.
* Replace bodies of Comparable versions with calls to sort(by:)
* Make _insertionSort a method
* Make _sort3 a method
* Make _partition a method
* Make _introSort a method
* Make _siftDown, _heapify, _heapsort methods
* Other minor cleanup
* Document that removeAll(where:) doesn't reorder the remaining elements.
Per Swift Forums discussion on the topic:
"Does removeAll(where:) on arrays guarantee preserved order of elements?"
* Copy docs from the first default impl up to the protocol requirement.
Per Nate's feedback on PR#18803.
The protocol requirement was missing a few extra sentences and a
code example.
* Fix a code example that would fail to remove negative odd integers.
Per feedback on the forums from Jens,
swap `== 1` with `!= 0` so that negative odd numbers would be
removed, too, if the example were modified to include some negative
numbers in the input array.
* stdlib: replace recursion in _siftDown with iteration
Iterative approach removes recursion overhead. Therefore performance
of sorting will be improved
If we know a key path component can be accessed as a stored property, then we should also know whether it's a `let` or not, so it should be safe to encode this in the key path pattern. Stage this change in by changing the number of bits used to store in-line offsets, fixing up the parts of the key path implementation that assumed that it took up the entire payload bitfield.
A Dictionary.removeValue(forKey:) benchmark regressed 35% because recent changes in this PR caused an _UnsafeBitMap member to not be inlined in its implementation. (This was probably triggered by moving a method from Dictionary._Variant to _NativeDictionary.)
Add @inline(__always) to _UnsafeBitMap members.
While we’re at it, make _UnsafeBitMap @usableFromInline. It’s only public for testing purposes.
This is primarily for documentation purposes, although the default implementation (based on an iterator) may not return the correct value for bridged dictionaries with exotic implementations.
- Inlinability audit
- Create a _NativeSet/_NativeDictionary directly, without extracting it from a Set/Dictionary
- Swap the final result with an empty collection.
- Nest native/cocoa index types under their corresponding struct
- Move *IndexRepresentation enums under the corresponding Index type, renamed to _Variant.
- Rename Index._value to Index._variant.
- Remove internal typealiases.
- Remove underscore prefix from enum case names.
- _nativeIndex => _asNative, _cocoaIndex => _asCocoa
- Audit inlinability.
- Rename variant enum types and move them into the corresponding struct:
_VariantSetBuffer => Set._Variant
_VariantDictionaryBuffer => Dictionary._Variant
I found the buffer suffix did not positively contribute to understanding these types. And the extra indirection of the typealiases wasn't exactly helpful, either.
- Remove internal typealiases that resolved to these.
On Windows, `__swift_stdlib_UNumericType` and `__swift_stdlib_UCharCategory` are imported as `Int32`s rather than `UInt32`. Change the constructors to use the type's inferred `RawValue` rather than always `UInt32`.
