The async refactorings ignore whether a completion handler had
`@escaping` or not. In preparation of fixing this, fix up all functions
to have `@escaping` for their completion handler parameter.
Also some small miscellaneous fixes in order to reduce the number of
warnings output on test failures and also the addition of `REQUIRES:
concurrency` on all tests.
Previously we only supported `case` patterns that bound with a `let` inside the associated value like `case .success(let value)`. With this change, we also support `case let .success(value)`.
Fixes rdar://79279846 [SR-14772]
If we're going to be classifying nodes in either
an `else if` block or after a `guard` statement
with a known condition path, be more lenient with
unhandled conditions, as we already know what path
they should be classified along.
rdar://78564388
If we're in a case stmt body, any DeclRefExprs
to vars bound by a pattern will actually be to an
implicit var decl that's declared for the body. We
therefore need to walk to its "parent" to get to
the var referenced by the pattern, which will have
the correct entries in the naming and placeholder
maps.
Keep track of patterns that bind multiple vars and
print them out when converting an async call. If
the parameter being bound isn't referenced elsewhere,
we'll print the pattern inline as e.g:
```
let ((x, y), z) = await foo()
```
Otherwise, if the parameter is referenced elsewhere
in the block we'll print the pattern out of line,
such as:
```
let (res, z) = await foo()
let (x, y) = res
```
In addition, make sure to print var bindings out
of line if there's also a let binding, e.g:
```
let x = await foo()
var y = x
```
This ensures any mutations to y doesn't affect x.
If there's only a single var binding, we'll print
it inline.
rdar://77802560
