Instead, 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.
I added a disable flag -disable-region-based-isolation-with-strict-concurrency
so that we do not need to update the current tests. It is only available when
asserts are enabled to ensure users cannot use it.
rdar://125918028
The newly-introduced associated type `AsyncSequence.Failure` must
always be equivalent to the `Failure` type of the
`AsyncIteratorProtocol`. If the `AsyncSequence` type itself defines a
nested `Failure` type (say, for another purpose), associated type inference
would pick it and reject the `AsyncSequence`, causing a source compatibility
problem.
Work around the issue in two ways. First, always infer the type
witness for `AsyncSequence.Failure` from the type witness for
`AsyncIteratorProtocol.Failure`, so they can't be out of sync. This
means that we'll never even consider a nested `Failure` type in the
`AsyncSequence`-conforming type. This hack only applies prior to Swift 6.
Second, when we have inferred a `Failure` type and there is already
something else called `Failure` within that same nominal type, don't
print the inferred typelias into a module interface because it will
cause a conflict.
Fixes rdar://123543633.
Our decision procedure for what type of error is thrown during
iteration of an async sequence was effectively duplicated between the
checking for the next/nextElement call (which is synthesized) and
separate logic for the async for..in loop. The latter is strictly
redundant, so switch to relying only on the former.
This is staging for customizing the next/nextElement call further.
This couples together several changes to move entirely from
`@rethrows` over to typed throws:
* Use the `Failure` type to determine whether an async for-each loop
will throw, rather than depending on rethrows checking
* Introduce a special carve-out for `rethrows` functions that have a
generic requirement on an `AsyncSequence` or `AsyncIteratorProtocol`,
which uses that requirement's `Failure` type as potentially being part
of the thrown error type. This allows existing generic functions like
the following to continue to work:
func f<S: AsyncSequence>(_: S) rethrows
* Switch SIL generation for the async for-each loop from the prior
`next()` over to the typed-throws version `_nextElement`.
* Remove `@rethrows` from `AsyncSequence` and `AsyncIteratorProtocol`
entirely. We are now fully dependent on typed throws.
This means that:
1. In test cases where minimal is the default (swift 5 without
-warn-concurrency), I added RUN lines for targeted, complete, and complete +
sns.
2. In test cases where complete is the default (swift 6, -warn-concurrency,
specified complete with -strict-concurrency), I added a send non-sendable run
line.
In each of these cases, I added additional expected-* lines as appropriate so
the tests can compile in each mode successfully.
For synthesized `<async iterator>.next()` calls expression rewriter
has to check whether witness is throwing and add `try` when necessary,
in order to do that injector needs to look through opened existentials,
erasures, and other implicitly injected AST nodes.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
If `async` effect has been inferred from the body of the closure,
let's find out the first occurrence of `async` node and point it out
to make it clear why closure is `async`.
Resolves: rdar://70610141
AsyncSequence is only polymorphic over 'throws' effects, not 'async',
because it is @rethrows and not @reasync. So the logic here was wrong,
and it would incorrectly conclude that a 'for await' with a concrete
conformance did not require the outer function to be 'async'.
Fixes rdar://problem/75436909.
This allows programs to target older OSes while using Concurrency behind an availability check. When targeting older OSes, the symbols are weak-linked and the compiler will require the use of Concurrency features to be guarded by an availability check.
rdar://75850003
Previously we diagnosed here if a thrown error was
unhandled, but we also have to set the flag, otherwise
we produce a warning saying that a 'do/catch' has
no throwing operations in its body.
Fixes rdar://problem/75274975.
SILGen verification crash when no other async functions are called in a function body not marked as async when a for-await-in syntax is used. This corrects the diagnostics to ensure that the type check effects sees the proper async call that the for-await-in syntax infers.
for-await-in syntax was missing a diagnistic hint for inserting a try when the protocol conformance of the sequence shows a potential of throwing. (also there was a superfluous check for the nominal type in that type check (which was removed).
for-await-in syntax and for-try-await-in syntax did not infer async or throwing to closure constraints, both were added to properly identify the asyncy-ness/throwy-ness of the iteration.
