Old Swift and new Swift runtimes and overlays need to coexist in the same process. This means there must not be any classes which have the same ObjC runtime name in old and new, because the ObjC runtime doesn't like name collisions.
When possible without breaking source compatibility, classes were renamed in Swift, which results in a different ObjC name.
Public classes were renamed only on the ObjC side using the @_objcRuntimeName attribute.
This is similar to the work done in pull request #19295. That only renamed @objc classes. This renames all of the others, since even pure Swift classes still get an ObjC name.
rdar://problem/46646438
* Revise the Unicode scalar/Character properties
* Minor revisions to `compactMapValues` docs.
* Add documentation for AdditiveArithmetic, revise Numeric
* Apply minor style updates to count(where:).
* Revise string interpolation docs.
- Convert table of interpolation examples to a list of examples. Tables
aren't supported by Swift markup, so this wouldn't render properly in
Xcode or on the web.
- Add a description of what a user must implement in a custom
string interpolation type to get the behavior they want.
* Revise isMultiple(of:) docs.
- In particular, add emphasis to mathematical symbols and equations to
match how we document such things elsewhere.
- I'm using asterisks for single symbols, and underscores for equations
because it's easier to read in-source when you don't have to escape
multiplication within emphasis.
* Add some abstracts to the SIMD vector types.
- Adds a dictionary of spelled out numbers. Only numbers < 10
should be spelled out according to editorial.
- Adds abstracts to some of the basic members.
- Includes parameter descriptions for the xyzw properties and inits,
but not for the unlabeled initializers. Combined with the protocol
extension method abstracts, this should complete coverage of the concrete
types.
The first change is to remove some @inline(__always) attributes. Those were added before we had the guaranteed-by-default calling convention. They are not necessary anymore.
The second change is to not specialize some slow-path functions. This results that no specialization code for these functions is generated at the client side. Instead those functions are directly called in the libSwiftCore.
Note that Key-related hash and equality comparisons are still specialized, because otherwise the performance hit for Osize would be too big.
Some Dictionary benchmarks regress a bit with -Osize, but the code size wins are big.
rdar://problem/46534453
_modify mustn’t leave Collection storage in an inconsistent state when the code to which we’re yielding happens to throw. In practice this means that any cleanup code must happen in defer blocks before the yield.
Fix Dictionary to do just that and add tests to cover this functionality (as well as some other aspects of _modify).
It took me a little while to figure out why we were fatalError()ing in such a convoluted way in Dictionary.init(uniqueKeysWithValues:); the next person to look at this code won’t waste that time.
_BridgeObject turned out not to be a great choice, because it doesn’t support tagged values on 32-bit platforms. Extracting the offset from index storage is a good idea anyway!
* [stdlib] Minor documentation revisions
* [docs] Convert 'nonoptional' to 'non-optional'
We're switching to 'non-optional' across the board, as the unhyphenated
form is too easy to read as 'no-noptional'.
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.
