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.
