Seems that the change in the two variables was spilling into the other
target of the file, but returning it back to the original values seems
to avoid that issue.
This should unbreak the Android CI build. In it, the Linux static
library was changing to the host compiler, and that compiler was being
used for the Android runtime library, which would have never compile
that way (since the host compiler in CI is an old-ish Clang without the
necessary argument).
In our initial approach for resolving metadata dependency cycles with classes, non-transitively complete superclass metadata was fetched by the subclass's metadata completion function and passed to `swift_initClassMetadata`. That could mean generating quite a lot of code in the completion function, and so we fairly recently changed it so that `swift_initClassMetadata` instead fetched the superclass metadata via a demangling. Unfortunately, the metadata demangler only fetches _abstract_ metadata by default, and class metadata cannot be considered even non-transitively complete when its superclass reference not at that stage. If the superclass metadata is being completed on one thread, and a subclass is being completed on another, and the subclass installs the incomplete superclass metadata in its superclass field and attempts to register the subclass with the Objective-C runtime, the runtime may crash reading the incompletely-initialized superclass.
The proper fix is to make `swift_initClassMetadata` fetch non-transitively complete metadata for the superclass, delaying completion if that metadata is unavailable. Unfortunately, that can't actually be implemented on top of `swift_initClassMetadata` because that function has no means of reporting an unsatisfied dependency to its caller, and we can no longer simply change its signature without worrying about a small of internal code that might still be using it. We cannot simply perform a blocking metadata request in `swift_initClassMetadata` because it is deeply problematic to block within a metadata completion function. The solution is therefore to add a `swift_initClassMetadata2` which has the ability to report unsatisfied dependencies. That was done in #22386; this patch builds on that by teaching the compiler to generate code to actually use it. It is therefore not safe to use this patch if you might be running on an OS that only provides the old runtime function, but that should be a temporary Apple-internal problem.
Fixes rdar://47549859.
This is a cleaner, more principled way of adding "compiler launcher" support and
ensures that cmake understands that distcc is not the "actual" compiler.
This ensures that when we compile SwiftRemoteMirrors for the host, we do not try
to compile using distcc without needing to reset CMAKE_{C,CXX}_COMPILER_ARG1
(which is unset when compiling things in the stdlib).
Note that I've called out a couple of suspicious places where we
are requesting abstract metadata for superclasses but probably
need to be requesting something more complete.
The debug build of the standard library on Windows does not generate the
import library for SwiftOnoneSupport which prevents the build of debug
programs against the debug runtime. Because the linker must find the
import library in order to satisfy the forced link that we emit for the
link against the SwiftOnoneSupport library, without this, the build is
not usable. Furthermore, this requires a debug build of the runtime
since in the optimized build, the interfaces that this library provides
are not provided by swiftCore and this supplements the library to allow
building the debug program.
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
