A protocol conformance can be ill-formed due to isolation mismatches
between witnesses and requirements, or with associated conformances.
Previously, such failures would be emitted as a number of separate
errors (downgraded to warnings in Swift 5), one for each witness and
potentially an extra for associated conformances. The rest was a
potential flood of diagnostics that was hard to sort through.
Collect all of the isolation-related problems for a given conformance
together and produce a single error (downgraded to a warning when
appropriate) that describes the overall issue. That error will have up
to three notes suggesting specific courses of action:
* Isolating the conformance (when the experimental feature is enabled)
* Marking the witnesses as 'nonisolated' where needed
*
The diagnostic also has notes to point out the witnesses/associated
conformances that have isolation problems. There is a new educational
note that also describes these options.
We give the same treatment to missing 'distributed' on witnesses to a
distributed protocol.
When diagnosing an isolation mismatch between a requirement and witness,
we would produce notes on the requirement itself suggesting the addition of
`async`. This is almost never what you want to do, and is often so far
away from the actual conforming type as to be useless. Remove this note,
and the non-function fallback that just points at the requirement, because
they are unhelpful.
This is staging for a rework of the way we deal with conformance-level
actor isolation problems.
`x declared here` is not helpful and clear enough, especially when there
are other notes attached. Swap it for a new note that says
`requirement x declared here`.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
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.
A `@preconcurrency` conformance to an inherited protocol should imply
`@preconcurrency` on its parents as well. For example:
```swift
protocol Parent {
func a()
}
protocol Child: Parent {
func b()
}
@MainActor
class Test: @preconcurrency Child {
func a() {
}
func b() {
}
}
```
`Test` conformance to `Parent` implied by its conformance to `Child`
should carry `@preconcurrency` and inject dynamic actor isolation checks
to witness of `a()`.
Resolves: https://github.com/apple/swift/issues/74294
Resolves: rdar://129599097
When a witness is part of a `@preconcurrency` conformance, suppress
Sendable checking for that witness because we assume that the caller is
correctly invoking this witness from within the right isolation
domain. This property is dynamically checked.
Fixes https://github.com/apple/swift/issues/74057.
When diagnosing a case where an actor-isolated witness cannot satisfy
a non-isolated requirement, also suggest that the conformance could be
annotated with `@preconcurrency`.
Suppress warnings/errors when actor isolated synchroneous witness
is matched against `@preconcurrency` conformance requirement.
Witness thunk assumes isolation of the witness but instead of a
hop to its executor it would emit a runtime check to make sure
that its always called from the expected context.
