This is a follow-up to https://github.com/swiftlang/swift/pull/82085
which made it so async variant doesn't get `@Sendable` inferred because
the proposal specified that inference should happen only on completion
handler parameter type of a synchronous variant of an imported API.
This runs into implementation issues related to thunking in some
cases were async convention expects the type of a completion handler
to match exactly for both variants of the imported API.
Resolves: rdar://154695053
(cherry picked from commit 30f0fa8d75)
This lifts the check for the feature flag up into the `importParameterType`
from `importType` and means that completion handler type for `async` variant
is no longer gains `@Sendable` attribute.
(cherry picked from commit 74471e858b)
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
The reason why I am doing this is that the unlike the codegen for checked
continuation, the codegen for unchecked continuation uses a sendable value
instead of Any as the block storage which prevents me from being able to create
a dependency from a non-Sendable @out parameter to the block.
By changing to use Any consistently, we are able to take advantage of Any not
being sendable to properly propagate this information.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
Async functions are now expected to set ExpectedExecutor in their
prologue (and, generally, immediately hop to it). I updated the
prologue code for a bunch of function emission, most of which was
uninteresting. Top-level code was not returning to the main
executor, which is now fixed; fortunately, we weren't assuming
that we were on the main executor yet.
We had some code that only kicked in when an ExpectedExecutor
wasn't set which made us capture the current executor before
a hop and then return to it later. This code has been removed;
there's no situation in which save-and-return is the semantically
correct thing to do given the possibility of hop optimization.
I suspect it could also have led to crashes if the current
executor is being kept alive only because it's currently running
code. If we ever add async functions that are supposed to inherit
their caller's executor, we should have the caller pass the right
executor down to it.
This is the first half of SE-0338; the second, sendability
enforcement, is much more complicated, and Doug has volunteered
to do it.
Fixes rdar://79284465, as well as some tests that were XFAILed
on Windows.
1. Removes gating on -enable-experimental-concurrency.
2. Updates eff. prop tests to remove experimental flag,
and also adjusts some tests slightly to avoid things
that are still behind that flag.
