Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
When SWIFT_COMPACT_ABSOLUTE_FUNCTION_POINTER is enabled, relative direct
pointers whose pointees are functions will be turned into absolute
pointer at compile-time.
The immediate use case is only concretely-constrained existential
types, which could use a much simpler representation, but I've
future-proofed the representation as much as I can; thus, the
requirement signature can have arbitrary parameters and
requirements, and the type can have an arbitrary type as the
sub-expression. The latter is also necessary for existential
metatypes.
The chief implementation complexity here is that we must be able
to agree on the identity of an existential type that might be
produced by substitution. Thus, for example, `any P<T>` when
`T == Int` must resolve to the same type metadata as
`any P<Int>`. To handle this, we identify the "shape" of the
existential type, consisting of those parts which cannot possibly
be the result of substitution, and then abstract the substitutable
"holes" as an application of a generalization signature. That
algorithm will come in a later patch; this patch just represents
it.
Uniquing existential shapes from the requirements would be quite
complex because of all the symbolic mangled names they use.
This is particularly true because it's not reasonable to require
translation units to agree about what portions they mangle vs.
reference symbolically. Instead, we expect the compiler to do
a cryptographic hash of a mangling of the shape, then use that
as the unique key identifying the shape.
This is just the core representation and runtime interface; other
parts of the runtime, such as dynamic casting and demangling
support, will come later.
* When ptrauth-copying vtable/wtables, allow NULL entries (due to VFE)
* Mark virtual-function-elimination-generics-exec.swift UNSUPPORTED: arm64e until the rebranch
* Fix test expectations
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
SWIFT_CLASS_IS_SWIFT_MASK is optionally defined to a global variable _swift_classIsSwiftMask, which allows the runtime to choose the appropriate mask when running on OS versions earlier than macOS 10.14.4. This is no longer a supported target for newly built runtimes (Swift apps built with such a target will embed a copy of the back deployment runtime, which is separate) and this global is no longer useful. Instead, unconditionally define SWIFT_CLASS_IS_SWIFT_MASK to 2 on Apple platforms, which is the correct value for current OS versions.
rdar://48413153
Previously, AsyncFunctionPointer constants were signed as code. That
was incorrect considering that these constants are in fact data. Here,
that is fixed.
rdar://76118522
Fill out the metadata for Job to have a Dispatch-compatible vtable. When available, use the dispatch_enqueue_onto_queue_4Swift to enqueue Jobs directly onto queues. Otherwise, keep using dispatch_async_f as we have been.
rdar://75227953
Certain targets don't support the async calling convention, so we first
add the feature check to avoid breaking the codegen/runtime while doing
gradual rollout for different targets.
* Adds support for generating code that uses swiftasync parameter lowering.
* Currently only arm64's llvm lowering supports the swift_async_context_addr intrinsic.
* Add arm64e pointer signing of updated swift_async_context_addr.
This commit needs the PR llvm-project#2291.
* [runtime] unittests should use just-built compiler if the runtime did
This will start to matter with the introduction of usage of swiftasync parameters which only very recent compilers support.
rdar://71499498
There are things about this that I'm far from sold on. In
particular, I'm concerned that in order to implement escalation
correctly, we're going to have to add a status record for the
fact that the task is being executed, which means we're going
to have to potentially wait to acquire the status lock; overall,
that means making an extra runtime function call and doing some
atomics whenever we resume or suspend a task, which is an
uncomfortable amount of overhead.
The testing here is pretty grossly inadequate, but I wanted to
lay down the groundwork here.
The runtime that shipped with Swift 5.1 and earlier had a bug that interfered with backward
deployment of binaries that dynamically check for protocol conformances on conditionally-available
tests. This was fixed in the top-of-tree Swift runtime by https://github.com/apple/swift/pull/29887;
however, that doesn't do much good for running binaries on older OSes that don't have that fix.
In order for binaries built with a newer Swift compiler to run successfully on older OSes,
introduce a compatibility hook that replaces the conformance cache implementation in the original
OS runtime with a version based on the current implementation that has the fix for the protocol
conformance bug. Fixes rdar://problem/59460603
This could fail to build due to BackDeployment.h not always being included in Config.h. Check an additional condition to ensure that this code is only active when BackDeployment.h is included.
rdar://problem/56735154
Recent Swift uses 2 as the is-Swift bit when running on newer versions, and 1 on older versions. Since it's difficult or impossible to know what we'll be running on at build time, make the selection at runtime.
* cmake: Propagate SWIFT_DARWIN_ENABLE_STABLE_ABI_BIT to overlay builds.
* runtime: Clear the correct bit in getROData()
* test/IRGen/objc_class_export.swift: Allow either is-Swift bit.
* test/stdlib/SwiftObjectNSObject.swift: Allow either name for SwiftObject.
The runtime doesn't really need Compiler.h. It just needs some
visibility macros which can be inlined here instead of pulling
the whole heavyweight header (including its transitive closure,
llvm-config.h). This is becoming more important now that Compiler.h
includes C++ headers (namely, <new>), and swift/Runtime/Config.h
can be included from C or Objective-C files (causing build failures).
<rdar://problem/35860874>
Expansion of undefined macros is 0. This results in warnings when
building the runtime on Windows. Ensure that the macros are defined
when checking the conditions. NFC.
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
clang is miscompiling some swiftcall functions on armv7s.
Stop using swiftcall in some places until it is fixed.
Reverts c5bf2ec (#13299).
rdar://35973477
These are temporary staging macros to ease having a runtime that supports both
+0 and +1 conventions for functions exposed as Swift level functions in the
stdlib (and thus needing to follow the swift convention). The macros values are
toggled by the argument SWIFT_ENABLE_GUARANTEED_NORMAL_ARGUMENTS and thus have
values described via the following table:
| SWIFT_ENABLE_GUARANTEED_NORMAL_ARGUMENT | FALSE | TRUE |
|-----------------------------------------+-------------------------------+-------------------------------|
| SWIFT_NS_RELEASES_ARGUMENT | NS_RELEASES_ARGUMENT | "" |
| SWIFT_CC_PLUSONE_GUARD(...) | do { __VA_ARGS__ ; } while(0) | "" |
| SWIFT_CC_PLUSZERO_GUARD(...) | "" | do { __VA_ARGS__ ; } while(0) |
Thus instead of having to write an ugly #ifdef multiple times in each function
(for the arguments, destroys, and retains), we can just use these macros
instead.
In a subsequent commit I am going to cleanup the changes I made in the runtime
already to use these macros. So this is a NFC change.
rdar://34222540
Swift class metadata has a bit to distinguish it from non-Swift Objective-C
classes. The stable ABI will use a different bit so that stable Swift and
pre-stable Swift can be distinguished from each other.
No bits are actually changed yet. Enabling the new bit needs to wait for
other coordination such as libobjc.
rdar://35767811
This is a blanket pass replacing use of `__LP64__` with
`__POINTER_WIDTH__ == 64`. The latter is more expressive and also LLP64
clean. This change is needed to enable support for Windows x86_64 which
is a LLP64 environment.
Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
