The code that saves/restores the exclusivity checks for tasks was
newly introduced into the runtime. Clone that code into the back-
deployed version of the runtime.
The runtime support functions are currently vended by
swiftCore.{dll,dylib,so} rather than
swift_Differentiation.{dll,dylib,so}. This corrects the annotations to
indicate that reality. This never could have worked as declared in the
first place. swift_Differentiation never links against swiftRuntime
and swiftCore effectively whole-archives swiftRuntime into itself. This
change is now reflecting that reality. If the desire is to move this
(even on Darwin, where this may have already shipped and thus would
break ABI), we could split up the swiftRuntime into swiftRuntime and
swiftDifferentiationRuntime and link that as we do with the runtime into
swiftCore.
Added a new test to the test suite that round trips Swift types through
mangled names and checks that we get the same type back that we started
with.
rdar://37170485
Moved the test for the metadata kind to MetadataLookup.cpp.
Added an assertion (for debug builds) to Metadata.cpp to catch the case where
something manages to bypass that test.
Added a special test for getObjCClassByMangledName; this needs testing
separately as it uses the DecodedMetadataBuilder, which doesn't get exercised
by the normal demangling tests.
Added all the test cases from rdar://63485806, rdar://63488139, rdar://63496478,
rdar://63410196 and rdar://68449341. The test cases from rdar://63485806 are
disabled for now because the problem there is the error handling mechanism (or
lack thereof), rather than us not handling errors.
Fixes the remaining cases from
rdar://63488139
rdar://63496478
Replace the `static std::mutex` with Swift's `StaticMutex` so that we
avoid triggering an error due to an exit time destructor. Repairs the
build after #38562.
Some notes:
1. Even though I refactored out AccessSet/Access from Exclusivity.cpp ->
ExclusivityPrivate.h, I left the actual implementations of insert/remove in
Exclusivity.cpp to allow for the most aggressive optimization for use in
Exclusivity.cpp without exposing a bunch of internal details to other parts of
the runtime. Smaller routines like getHead() and manipulating the linked list
directly I left as methods that can be used by other parts of the runtime. I am
going to use these methods to enable backwards deployment of exclusivity support
for concurrency.
2. I moved function replacements out of the Exclusivity header/cpp files since
it has nothing to do with Exclusivity beyond taking advantage of the TLS context
that we are already using.
The specific environment variable is SWIFT_DEBUG_RUNTIME_EXCLUSIVITY_LOGGING. We only
check the environment the first time we try to lookup the TLSContext, so it
shouldn't impact exclusivity performance.
My intention is to use this to write some FileCheck tests so that we can really
be sure that the runtime is doing what we think it is. As such I also changed
the small amount of logging routines meant for use in the debugger to use stdout.
The implemented semantics are that:
1. Tasks have separate exclusivity access sets.
2. Any synchronous context that creates tasks will have its exclusive access set
merged into the Tasks while the Task is running.
rdar://80492364
Conformance checks now walk the superclass chain in two stages: stage 1 only walks superclasses that have already been instantiated. When there's a negative result and there's an uninstantiated superclass, then stage 2 will walk the uninstantiated superclasses.
The infinite recursion would occur in this scenario:
class Super<T: P> {}
class Sub: Super<Sub>, P {}
Instantiating the metadata for Super requires looking up the conformance for Sub: P. Conformance checking for Sub would instantiate the metadata for Super to check for a Super: P conformance.
The compiler does not allow the conformance to come from a superclass in this situation. This does not compile:
class Super<T: P>: P {}
class Sub: Super<Sub> {}
Therefore it's not necessary to look at Super when finding the conformance for Sub: P in this particular case. The trick is knowing when to skip Super.
We do need to instantiate Super in the general case, otherwise we can get false negatives. This was addressed in a80fe8536b, which walks the full superclass chain during conformance checks, even if the superclass has not yet been instantiated. Unfortunately, that causes this infinite recursion.
This fix modifies that fix to make superclass instantiation conditional. The result is the ability to choose between the old algorithm (which skipped uninstantiated superclasses, albeit somewhat by accident) and the new one. A small wrapper then runs the check with the old algorithm, and then only if the old algorithm fails and there is an uninstantiated superclass, it runs with the new one.
Uninstantiated superclasses are uncommon and transient (you only run into this while metadata is in the process of being constructed) so 99.9999% of the time we'll just run the first stage and be done, and performance should remain the same as before.
rdar://80532245
I ran into this while implementing
async actor inits; where I was emitting
an actor hop in the middle of
an access region, which caused the
access set to be unexpectedly empty.
The getSuperclassForMaybeIncompleteMetadata function assumes Swift metadata, and can malfunction strangely when given a pure ObjC class. This is rare, as we usually get the Swift wrapper metadata instead, but possible when using calls like objc_copyClassList.
Fix this by checking for isTypeMetadata before doing anything that assumes Swift-metadata-ness.
rdar://80336030
When witness tables for enums are instantiated at runtime via
swift::swift_initEnumMetadataMultiPayload
the witnesses
getEnumTagSinglePayload
storeEnumTagSinglePayload
are filled with swift_getMultiPayloadEnumTagSinglePayload (previously
getMultiPayloadEnumTagSinglePayload) and
swift_storeMultiPayloadEnumTagSinglePayload (previously
storeMultiPayloadEnumTagSinglePayload). Concretely, that occurs when
instantiating the value witness table for a generic enum which has more
than one case with a payload, like Result<T>. To enable the compiler to
do the same work, those functions need to be visible to it.
Here, those functions are made visible to the compiler. Doing so
requires changing the way they are declared and adding them to
RuntimeFunctions.def which in turn requires the definition of some
functions to describe the availability of those functions.
The conditional should have been "Intel simulators" but it was actually "x86-64 simulators." The i386 simulator doesn't have the weak formation callout, which causes it to miss cleaning up associated objects when the Swift runtime thinks it does.
rdar://79672466
Added SWIFT_RUNTIME_WEAK_IMPORT/CHECK/USE macros.
Everything supports fast dealloc except x86 iOS simulators, so we no longer need
to look up objc_has_weak_formation_callout.
Added direct references for
objc_setHook_lazyClassNamer
_objc_realizeClassFromSwift
objc_setHook_getClass
os_system_version_get_current_version
_dyld_is_objc_constant
tryGetCompleteMetadataNonblocking crashes on artificial subclasses due to the NULL type descriptor. Explicitly check for artificial subclasses in getSuperclassForMaybeIncompleteMetadata and immediately return their Superclass field. Artificial subclasses are always fully initialized so we don't need to do anything special for them.
rdar://72583931
When we rely on a protocol conformance, and the type in question has multiple
conformances to that protocol in its inheritance chain, emit a runtime warning.
It's quite tricky to cause this problem - you need a type in one dylib that is
extended to conform to a protocol in another dylib, subclassed in another module
and then some subclass has protocol conformance added as well. If they're in
the same module, the compiler will give an error and prevent the problem
completely.
rdar://73364629
Isolated parameters are part of function types. Encode them in function
type manglings and metadata, and ensure that they round-trip through
the various mangling and metadata facilities. This nails down the ABI
for isolated parameters.
`_environ` is meant to be DLL imported when linking against the C
runtime dynamically (`/MD` or `/MDd`). However, when building for
the Windows Runtime environment, we cannot support the use of `_environ`
and thus disable the support for that. `_WINRT_DLL` identifies the
combination of `/ZW` and `/LD` or `/LDd`. Windows Runtime builds cannot
be executables (and obviously not static libraries as they are not
executable), and thus we properly disable `ENVIRON` in all Windows
Runtime builds.
