It is unfortunate that `Unsafe[Raw]BufferPointer._pointer` and
`baseAddress` are declared Optional. This leaves extra runtime checks
in the code in the most performance critical paths. Contrast this with
Array, which uses an sentinal pointer for the empty representation.
This forces us to use _unsafelyUnwrappedUnchecked whenever we just
want to dereference a non-empty buffer pointer.
Fixes SR-9809: swiftc appears to make some sub-optimal optimization choices
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
Without this change, SILGen will crash when compiling a use of the
derived protocol's requirement: it will instead attempt to use
the base protocol's requirement, but the code will have been
type-checked incorrectly for that.
This has a potential for source-compatibility impact if anyone's
using explicit override checking for their protocol requirements:
reasonable idioms like overriding a mutating requirement with a
non-mutating one will no longer count as an override. However,
this is arguably a bug-fix, because the current designed intent
of protocol override checking is to not allow any differences in
type, even "covariant" changes like making a mutating requirement
non-mutating. Moreover, we believe explicit override checking in
protocols is quite uncommon, so the overall compatibility impact
will be low.
This also has a potential for ABI impact whenever something that
was once an override becomes a non-override and thus requires a
new entry. It might require a contrived test case to demonstrate
that while using the derived entry, but it's quite possible to
imagine a situation where the derived entry is not used directly
but nonetheless has ABI impact.
Furthermore, as part of developing this patch (earlier versions of
which used stricter rules in places), I discovered a number of
places where the standard library was unintentionally introducing
a new requirement in a derived protocol when it intended only to
guide associated type deduction. Fixing that (as I have in this
patch) *definitely* has ABI impact.
MetadataLookup gives special treatment to imported Objective-C classes,
since there's no nominal type descriptor and metadata is obtained
directly by calling into the Objective-C runtime.
Remote reflection also gives special treatment to imported Objective-C
classes; they don't have field descriptors.
However, the ASTDemangler needs to treat them like ordinary classes,
in particular it wants to preserve the generic arguments here so that
we can round-trip debug info.
If we nest a type inside a local context inside a generic type,
we have to look through the local context(s) to find the outer
generic type when stripping off generic arguments.
We don't support nominal types inside generic local context
right now, but this can happen with type aliases.
The part of the tag stored in the payload can currently be up to
8 bytes in size (though only the 'low' 4 bytes can be non-zero).
On little-endian machines this doesn't matter, we can always just
store up to 4 bytes and zero the remaining payload bytes. On big-
endian systems however we may need to store more than 4 bytes.
The store implementation now mirrors the runtime code that fetches
the tag on big-endian systems which already treats the payload tag
as an 8 byte integer.
This is a spot fix but longer term we might want to consider
refactoring this code to reduce the number of differences between
big- and little-endian implementations. For example, we could
centralise some of the copying logic and/or make the payload tag
a 4 byte field on all platforms.
This adds an explicit version of the SwiftRemoteMirror library for use
in the tools that comprise the toolchain. This is a separate build from
the target specific builds of the library even though we may be building
the runtime for the (same) host.
The “string length” primitive was validating the string data as valid UTF-8
to get the length. However, mangled names, which get read by this operation,
are not always valid UTF-8. Just count the bytes until a ‘0’ and don’t
validate.
Debug info uses a special mangling where type aliases can be
represented without being desugared; attempt to reconstruct
the TypeAliasType in this case.