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.
When constructing generic type metadata, we can end up checking protocol conformances for metadata that isn't fully built, and in particular the superclass field may not be set up yet. Handle this case properly by falling back to looking up the superclass by mangled name from the nominal type descriptor when necessary.
Previously we were just chasing Superclass fields, which would cause us to terminate the search early sometimes when concurrently looking up the same type from multiple threads. When a protocol conformance is on a superclass, this causes the search to fail incorrectly, causing type lookup failures.
This only arises on the very first attempt to instantiate a given type, since the lookup will be cached (and all metadata fully initialized) after the first success.
rdar://72583931
Implement name mangling, type metadata, runtime demangling, etc. for
global-actor qualified function types. Ensure that the manglings
round-trip through the various subsystems.
Implements rdar://78269642.
Introduce a second level of standard substitutions to the mangling,
all of the form `Sc<character>`, and use it to provide standard
substitutions for most of the _Concurrency types.
This is a precursor to rdar://78269642 and a good mangling-size
optimization in its own right.
* SR-14635: Casts to NSCopying should not always succeed
The runtime dynamic casting logic explores a variety of strategies for
each cast request. One of the last options is to wrap the source
in a `__SwiftValue` box so it can bridge to Obj-C. The previous
code was overly aggressive about such boxing; it performed the boxing
for any source type and only checked to verify that the `__SwiftValue`
box itself was compatible with the destination.
Among other oddities, this results in the behavior discussed
in SR-14635, where any Swift or Obj-C type will always successfully cast
to NSCopying because `__SwiftValue` is compatible with NSCopying.
This is actually two subtly different issues:
* Class types should not be subject to `__SwiftValue` boxing at all.
Casting class types to class existentials is already handled elsewhere,
so this function should just reject any source with class type.
* Non-class types should be boxed only when being assigned to
an AnyObject (an "unconstrained class existential"). If
the class existential has constraints, it is by definition
a class-constrained existential which should not receive
any non-class object.
To solve these, this PR disables `__SwiftValue` boxing in two cases:
1. If the source is a class (reference) type.
2. If the destination has constraints
Resolves SR-14635
Resolves rdar://78224322
* Avoid boxing class metatypes on Darwin
But continue boxing
* Non-class metatypes on all platforms
* All metatypes on non-Darwin platforms
Obj-C interop requires that we do not box class metatypes;
those must be usable as simple pointers when passed to Obj-C.
But no other metatype is object-compatible, so we have to
continue boxing everything else.
* Split out ObjC-specific test cases
Rename duplicated `swift::fatalError` in `swiftRuntime` and `swift_Concurrency`.
Both `swiftRuntime` and `swift_Concurrency` had `swift::fatalError` implementation, but it causes symbol conflict with the `-static-stdlib` flag.
This patch removes one of the implementations in `swift_Concurrency` to avoid conflicts. Also added a test case to ensure that linking the Concurrency module with `-static-stdlib` works.
This issue was found by SwiftWasm test cases.
