Previously, the partially applied functions were not defined and as such
had no sizes. That resulted in downstream issues as an attempt was made
to replace the size in the AsyncFunctionPointer for the functions'
forwarders with the size in the AsyncFunctionPointer for functions
because the latter did not exist.
The `_Concurrency` module provides APIs and runtime entry points that
are part of the core Swift model, but are separated into their own
module because it's helpful for staging development.
Use the new `-module-abi-name` feature to mangle contents of the
`_Concurrency` module as if they were already in the Swift module.
This sets the ABI up for the `_Concurrency` module being merged in to
the Swift module at some future point without changing mangling or
metadata.
Fixes rdar://74285139.
The `coro.end.async` intrinsic allow specifying a function that is to be
tail-called as the last thing before returning.
LLVM lowering will inline the `must-tail-call` function argument to
`coro.end.async`. This `must-tail-call` function can contain a
`musttail` call.
```
define @my_must_tail_call_func(void (*)(i64) %fnptr, i64 %args) {
musttail call void %fnptr(i64 %args)
ret void
}
define @async_func() {
...
coro.end.async(..., @my_must_tail_call_func, %return_continuation, i64 %args)
unreachable
}
```
In their previous form, the non-`_f` variants of these entry points were unused, and IRGen
lowered the `createAsyncTask` builtins to use the `_f` variants with a large amount of caller-side
codegen to manually unpack closure values. Amid all this, it also failed to make anyone responsible
for releasing the closure context after the task completed, causing every task creation to leak.
Redo the `swift_task_create_*` entry points to accept the two words of an async closure value
directly, and unpack the closure to get its invocation entry point and initial context size
inside the runtime. (Also get rid of the non-future `swift_task_create` variant, since it's unused
and it's subtly different in a lot of hairy ways from the future forms. Better to add it later
when it's needed than to have a broken unexercised version now.)
The underlying runtime functions really want to be able to consume the closure being used
to spawn the task, but the implementation was trying to hide this by introducing a retain
at IRGen time, which is not very ARC-optimizer-friendly. Correctly model the builtin operands
as consumed so that the ownership verifier allows them to be taken +1.
This is conditional on UseAsyncLowering and in the future should also be
conditional on `clangTargetInfo.isSwiftAsyncCCSupported()` once that
support is merged.
Update tests to work either with swiftcc or swifttailcc.
Previously, the error stored in the async context was of type SwiftError
*. In order to enable the context to be callee released, make it
indirect and change its type to SwiftError **.
rdar://71378532
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
In __swift_async_resume_project_context, the context is stored into the
extended frame. On arm64e, it is signed first. Previously, that signed
context was returned fro the function. That resulted in code like
pacda x16, x10
str x16, [x9]
ldr x9, [x16, #0x48]
where the context is signed (pacda), stored into the extended frame
(str) and then an attempt is made to load from the signed context (ldr).
Here, the unsigned context is returned from the function.
The issue was resolved at https://github.com/apple/swift/pull/35695 .
Here, a test is added for the case of methods on generic types which
appear in a constrained extension.
rdar://72906989
EmitPolymorphicArguments puts the extra sources before the unfulfilled
requirements into the explosion. The NecessaryBindings instance must
have the type parameters in the same order. Previously, though, they
were added after enumerating unfulfilled requirements. Here, they are
added _before_ enumerating, matching the ordering of
EmitPolymorphicArguments.
rdar://73742483
Resilient witness tables and resilient class vtables are built from
descriptors. Make sure we reference the AsyncFunctionPointer of a
method implementation, and not the implementation itself, if the
method is async.
Part of rdar://problem/73625623.
This adds new kinds of link entities corresponding to the three
dispatch thunk link entity kinds:
- DispatchThunkAsyncFunctionPointer
- DispatchThunkInitializerAsyncFunctionPointer
- DispatchThunkAllocatorAsyncFunctionPointer
* 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
Previously, the "bare" linkage of a link entity was used to determine
whether to put an async function pointer into the tbd. That did not
match the mechanism by which the linkage was determined in IRGen.
There, the linkage is the "_effective_" linkage (i.e. the value returned
from SILFunction::getEffectiveSymbolLinkage).
Here, whether to put the async function pointer corresponding to a class
method is determined on the basis of that effective linkage.
rdar://problem/73203508
