By default avoid imploding params that have parameter
flags, but carve out exceptions for ownership flags,
which can be thunked, and `@_nonEphemeral` which can
be freely dropped without issue.
With the introduction of `isolated` as
a type modifier for actor types, the
parsing of a parameter regressed such
that `isolated` was no longer accepted
as an ordinary argument label. This patch
fixes that and adds a little lookahead
utility to clean-up the code that
disambiguates the uses of `isolated`
as either a label or a type modifier.
Resolves rdar://80300022
Rework the checking of actor member access to rely on "isolated" parameters
(and captures thereof) to determine whether one can synchronously access
an actor or not. This allows synchronous access via an "isolated" parameter
as a general notion, which subsumes the declaration-based "self" access.
Simplify the checking of and diagnostic reporting for actor member
access by collapsing a number of redundant diagnostics down into a
single, parameterized diagnostic with a single point of emission. This
normalizes the logic a bit.
With isolated parameters being part of a function's type, check to
ensure that isolated and non-isolated parameters aren't incorrectly
matched. Specifically, it is okay to add `isolated` to a parameter
when there is a subtyping relationship, but not remove it:
```swift
actor A { }
func f(_: isolated A) { }
func g(_: A) { }
func test() {
let _: (isolated A) -> Void = g // okay to add 'isolated'
let _: (A) -> Void = f // error when removing 'isolated'
}
```
The notion of "actor-isolated" currently exists at the declaration level.
For functions, it is going to be captured in the function type itself,
where 'self' is declared to be 'isolated'. Model isolation both
ways: the 'self' of a method that is isolated to an actor instance
will be 'isolated' as well.
We are still using declaration-based checking of actor isolation.
However, by mirroring this information we can move more incrementally
over to doing checking based on 'isolated' parameters.
