The global table was vulnerable to race conditions when making
observations concurrently on multiple threads. We can assume the
`NSKeyValueObservingCustomization` methods are invoked synchronously
when creating the observation, so we can use a per-thread table instead.
This per-thread table is still vulnerable in the event that an
implementation of `automaticallyNotifiesObservers(for:)` creates a new
observation using a different `KeyPath` with the same Obj-C path, but
this method really shouldn't be creating any observations of its own.
Unfortunately we can't include the class in the per-thread table key, as
this may produce incorrect results in the presence of subclasses.
rdar://problem/45567020 https://bugs.swift.org/browse/SR-9077
The previous implementation could return keyPaths other than the one
used to create the `NSSortDescriptor` in the event that any subsequent
observation, `NSExpression`, or `NSSortDescriptor` was created using a
different `KeyPath` that had the same Obj-C keypath value.
https://bugs.swift.org/browse/SR-9076
If the `NSKeyValueObservation` was being deinited on one thread while a
KVO change notice was being broadcast on another, it could end up trying
to handle the change notice concurrently with deiniting, which will
probably crash.
This also fixes a problem where it was swizzling `NSObject`'s
`observeValue(forKeyPath:of:change:context:)` implementation, which
resulted in potentially invoking undefined behavior if an observer ever
called up to `NSObject`'s implementation.
https://bugs.swift.org/browse/SR-9074https://bugs.swift.org/browse/SR-9075
Swizzling the methods in a different order ensures we don't overwrite
the public `NSObject` method until it's safe to call our replacement.
rdar://problem/36663633 https://bugs.swift.org/browse/SR-6795
Many Foundation initializers could benefit from faster string
construction and subsequent reads in Swift 5. Add UTF-8 fast paths for
when constructing a string from a valid UTF-8 code units.
JSONEcoder/Decoder get another underscore in their ObjC name, as the one with a single underscore conflicts with older Swifts that had _JSONEcoder/Decoder as internal rather than fileprivate.
_JSONEncoder/Decoder get another underscore in their Swift name to avoid conflicting with the ObjC name from the ones in older overlays.
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
Moving them out to SIMDOperators didn't help, but the type checker hack
might. Move them back into the Swift standard library where they belong,
but leave SIMDOperators there to smooth over any short-term
incompatibilities.
* Minor improvements to CGFloat
Apparently init(exactly:) was never implemented for CGFloat, so let's fix that. Also includes minor cleanup for the .magnitude property.
* Add transparent annotations to some other CGFloat things.
