The new definition diverges from the existing hashValue: it feeds all path components to the hasher, rather than just a limited subset.
Hashing all the bits that are compared in == is necessary to ensure proper operation of the hash table.
The initializer was originally introduced without proper availability; in https://github.com/apple/swift/pull/23643, we fixed this by applying the `@_alwaysEmitIntoClient` attribute. However, this had the unfortunate side-effect that the symbol disappeared from `libswiftCore.dylib`, which somehow confuses some simulator builds.
Try to figure out what’s happening by replacing the third closure argument with an integer return value. This changes the mangled name of the bulk initializer, which should make it more obvious how/why these builds fail.
rdar://problem/49479386
I refactored some of the if statements in URL.swift to be guard instead.
This made the code shorter and easier to read.
This mirrors my commit on swift-corelibs-foundation (PR #2034)
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
String.Index has an encodedOffset-based initializer and computed
property that exists for serialization purposes. It was documented as
UTF-16 in the SE proposal introducing it, which was String's
underlying encoding at the time, but the dream of String even then was
to abstract away whatever encoding happend to be used.
Serialization needs an explicit encoding for serialized indices to
make sense: the offsets need to align with the view. With String
utilizing UTF-8 encoding for native contents in Swift 5, serialization
isn't necessarily the most efficient in UTF-16.
Furthermore, the majority of usage of encodedOffset in the wild is
buggy and operates under the assumption that a UTF-16 code unit was a
Swift Character, which isn't even valid if the String is known to be
all-ASCII (because CR-LF).
This change introduces a pair of semantics-preserving alternatives to
encodedOffset that explicitly call out the UTF-16 assumption. These
serve as a gentle off-ramp for current mis-uses of encodedOffset.
This reproposes @lilyball’s fixes in https://github.com/apple/swift/pull/20103 while adding her fix to ensure observations are removed before observed objects in 32-bit testing.
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
