LLVM seems to not support this today. With ownership SSA, we now produce these
for accelerate for some reason, causing lldb/TestAccelerateSIMD.py to fail. I
debugged this with Adrian and we got this fix. I filed the radar below against
Adrian to fix.
rdar://74287800
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
LLVM does type based analysis on sret storage types. This is a problem
with non-fixed types whose storage type does not contain the non-fixed
part.
rdar://73778591
Usually debug info only ever describes the *result* of a projectBox
call. To display a boxed parameter of an async continuation object,
however, the debug info can only describe the box itself and thus also
needs to emit a box type for it so the debugger knows to call into
Remote Mirrors to unbox the value.
SR-14059
rdar://problem/73358988
Empty types (such as structs without stored properties) have a
meaningless value for their address. To avoid crashes in the Thread
Sanitizer runtime, rather than passing this unspecified value as
the address of the inout access, skip emission of the runtime call.
The bug allowing unspecified behavior here has been present since we
first added TSan support for checking Swift access races -- but codegen
changes on arm64 have recently made crashes due to the bug much more
likely.
rdar://problem/47686212
This adds new kinds of link entities corresponding to the three
dispatch thunk link entity kinds:
- DispatchThunkAsyncFunctionPointer
- DispatchThunkInitializerAsyncFunctionPointer
- DispatchThunkAllocatorAsyncFunctionPointer
* Initial draft of async sequences
* Adjust AsyncSequence associated type requirements
* Add a draft implementation of AsyncSequence and associated functionality
* Correct merge damage and rename from GeneratorProtocol to AsyncIteratorProtocol
* Add AsyncSequence types to the cmake lists
* Add cancellation support
* [DRAFT] Implementation of protocol conformance rethrowing
* Account for ASTVerifier passes to ensure throwing and by conformance rethrowing verifies appropriately
* Remove commented out code
* OtherConstructorDeclRefExpr can also be a source of a rethrowing kind function
* Re-order the checkApply logic to account for existing throwing calculations better
* Extract rethrowing calculation into smaller functions
* Allow for closures and protocol conformances to contribute to throwing
* Add unit tests for conformance based rethrowing
* Restrict rethrowing requirements to only protocols marked with @rethrows
* Correct logic for gating of `@rethrows` and adjust the determinates to be based upon throws and not rethrows spelling
* Attempt to unify the async sequence features together
* Reorder try await to latest syntax
* revert back to the inout diagnosis
* House mutations in local scope
* Revert "House mutations in local scope"
This reverts commit d91f1b25b59fff8e4be107c808895ff3f293b394.
* Adjust for inout diagnostics and fall back to original mutation strategy
* Convert async flag to source locations and add initial try support to for await in syntax
* Fix case typo of MinMax.swift
* Adjust rethrowing tests to account for changes associated with @rethrows
* Allow parsing and diagnostics associated with try applied to for await in syntax
* Correct the code-completion for @rethrows
* Additional corrections for the code-completion for @rethrows this time for the last in the list
* Handle throwing cases of iteration of async sequences
* restore building XCTest
* First wave of feedback fixes
* Rework constraints checking for async sequence for-try-await-in checking
* Allow testing of for-await-in parsing and silgen testing and add unit tests for both
* Remove async sequence operators for now
* Back out cancellation of AsyncIteratorProtocols
* Restructure protocol conformance throws checking and cache results
* remove some stray whitespaces
* Correct some merge damage
* Ensure the throwing determinate for applying for-await-in always has a valid value and adjust the for-await-in silgen test to reflect the cancel changes
* Squelch the python linter for line length
Currently, the convention for partially applying an async function is to
form a thick function consisting of (1) a pointer to the partial apply
forwarder and (2) a thick context containing the async context size.
Previously, the partial application of async methods--specifically, for
which the partial application of the non-async analog produced a simple
partial apply (meaning that their context was a single ref-counted
object in the form of self)--would result in a simple partial
application. Here, that error is addressed by never allowing the
partial application of async methods to produce a simple partial apply.
Eventually, when the complex temporary ABI for partial application of
async functions is unrolled, this change will need to be unrolled as
well.
This commit depends on changes to the coroutine-splitting pass in LLVM. Shadow
copies are also turned off for async function arguments, because they make it
impossible to track debug info during coroutine splitting. Instead we are
relying on LLVM's CoroSplit.cpp to emit shadow copies. The Swift frontend gives
CoroSplit license to move do this by describing the arguments using a
dbg.declare intrinsic, even though it points to chain of load/GEP/bitcase
instructions into the Swift context function argument.
rdar://71866936
For this, store those 3 values on the stack at function entry and update them with the return values of coro_suspend_async intrinsic calls.
This fixes a correctness issue, because the executor may be different after a resume.
It also is more efficient, because this means that the 3 values don't have to preserved in the context over a suspension point.
Previously, the thick context was passed as a fourth parameter to
partial apply forwarders. Here, the thick context is instead moved into
the async context at the local context position. To support this, the
local context is made always available.
As part of concurrency bringup, some workarounds were put in place to
enable the async cc execution tests to continue to run while enabling
async function SIL verification (specifically, that an async function
must be called from an async function) to land before we have the
Task.runDetached mechanism. Specifically, these workaround allow @main
to be annotated @async but continue to be emitted as if it were not
@async.
Now that we have a better mechanism in the form of runAsync, use that
instead.
rdar://problem/70597390
Previously, when lowering the entry point of an async function, the
parameters were lowered to explosions that matched those of sync
functions, namely native explosions. That is incorrect for async
functions where the structured values are within the async context.
Here, that error is fixed, by adding a new customization point to
NativeCCEntryPointArgumentEmission which behaves as before for sync
functions but which simply extracts an argument from the async context
for async functions.
rdar://problem/71260972
An AsyncFunctionPointer, defined in Task.h, is a struct consisting of
two i32s: (1) the relative address of the async function and (2) the
size of the async context to be allocated when calling that function.
Here, such structs are emitted for every async SILFunction that is
emitted.
I have a need to have SwitchEnum{,Addr}Inst have different base classes
(TermInst, OwnershipForwardingTermInst). To do this I need to add a template to
SwitchEnumInstBase so I can switch that BaseTy. Sadly since we are using
SwitchEnumInstBase as an ADT type as well as an actual base type for
Instructions, this is impossible to do without introducing a template in a ton
of places.
Rather than doing that, I changed the code that was using SwitchEnumInstBase as
an ADT to instead use a proper ADT SwitchEnumBranch. I am happy to change the
name as possible see fit (maybe SwitchEnumTerm?).
Previously, an IRGenFunction was being passed to the functions that
construct an AsyncContextLayout. That was not actually necessary and
prevented construction of the layout in contexts where no IRGenFunction
was present. Here that requirement is eased to requiring an IRGenModule
which is indeed required to construct an AsyncContextLayout.
This instructions ensures that all instructions, which need to run on the specified executor actually run on that executor.
For details see the description in SIL.rst.
Because all async functions have the same signature, namely
void(%swift.task*, %swift.executor*, %swift.context*)
it is always possible to provide access to the three argument values
(the current task, current executor, and current context) within an
IRGenFunction which is async. Here, that is provided in the form of
IRGenFunction::getAsyncExecutor,IRGenFunction::getAsyncContext, and
IRGenFunction::getAsyncTask.
The previous stage of bringup only had async functions taking a single
argument: the async context. The next stage will involve the task and
executor. Here, arguments are added for those values. To begin with,
null is always passed for these values.
