This includes a bunch of fixes. It is not exhaustive but fit my time boxed time
period I set aside to look at this today.
A quick non-exhaustive list:
1. I removed unnecessary verify-additional-prefix lines.
2. Split tests with typechecker error and non-typechecker error components.
3. Removed complete- lines that we used when testing w/without send
non sednable.
4. Translated complete-and-tns- lines to be just complete- since they are just
testing strict-concurrency=complete and we are not testing complete without
send non sendable anymore.
Such references used to be downgraded until Swift 6 but since the
context is `@preconcurrency` it should be possible for API authors
to introduce concurrency annotations such as `@Sendable` without
breaking clients even when they are compiled in Swift 6 mode.
Resolves: rdar://157061896
The compiler would previously accept use of `@_inheritActorContext`
on a parameter with a synchronous function type which wasn't marked
as `@isolated(any)`. That is incorrect because in such cases the
attribute has no effect and furthermore would prevent Sendable
and isolation checking.
Uses like that are currently diagnosed by the type-checker but we
need to go one step further and remove the effect in such case to
prevent invalid uses.
Resolves: rdar://143581268
No warnings with minimal checking, warnings with `strict-concurrency=complete` and
if declaration is `@preconcurrency` until next major swift version.
Resolves: rdar://151911135
Resolves: https://github.com/swiftlang/swift/issues/81739
Replaces generic `expression is 'async' but is not marked with 'await`
diagnostic with a tailed one for cases where there is an access to an
actor-isolated value outside of its actor without `await` keyword.
This makes the diagnostics for async and sync contexts consistent
and actually identifies a problem instead of simply pointing out
the solution.
Resolves: rdar://151720646
This matches send non sendable but importantly also makes it clear that we are
talking about something that doesn't conform to the Sendable protocol which is
capitalized.
rdar://151802975
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.
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.
Downgrade a mismatch on global actor attributes to a warning until
Swift 6 to enable class authors to introduce concurrency annotations
to overridable members.
Resolves: rdar://131347583
If existential is a protocol composition type where all of the
protocols are `@_marker`, narrowly allow coercion to its superclass
bound (if it matches). Both types have the same representation
which makes it okay.
This is only a problem in Swift 5 mode without strict concurrency
checks. In this mode `@preconcurrency` stripping happens
outside of the solver which means that no conversion restrictions
are recorded for members that got `& Sendable` stripped from
their types.
For example:
```swift
struct S {
@preconcurrency static let member: KeyPath<String, Int> & Sendable
}
func test() {
_ = S.member
}
```
Since `member` is `@preconcurrency` its type would get concurrency
annotations stripped, which includes `& Sendable` which means that
the solver uses `KeyPath<String, Int>` type for the reference and
not the original `KeyPath<String, Int> & Sendable`, this is a problem
for `ExprRewritter::adjustTypeForDeclReference` because conversion
between existential and its superclass bound requires a constraint
restriction which won't be available in this case.
Resolves: rdar://132700409
Downgrade a mismatch on `any Sendable` -> `Any` to a warning until
Swift 6 to enable class authors to introduce concurrency annotations
to overridable properties.
Resolves: rdar://122193606
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`.
Swift 5 mode.
When you annotate a ValueDecl with `@preconcurrency`, the compiler should allow
concurrency violations by downgrading errors in the actor isolation checker to
warnings in Swift 5 mode. Previously, the actor isolation checker only checked
whether the caller's context was preconcurrency when deciding to downgrade, so
referencing preconcurrency declarations directly remained errors. Preconcurrency
was also dropped when computing actor isolation for declarations imported from
clang, which are always preconcurrency.
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.
It's ok to drop the global-actor qualifier `@G` from a function's type if:
- the cast is happening in a context isolated to global-actor `G`
- the function value will not be `@Sendable`
- the function value is not `async`
It's primarily safe to drop the attribute because we're already in the
same isolation domain. So it's OK to simply drop the global-actor
if we prevent the value from later leaving that isolation domain.
This means we no longer need to warn about code like this:
```
@MainActor func doIt(_ x: [Int], _ f: @MainActor (Int) -> ()) {
x.forEach(f)
// warning: converting function value of type '@MainActor (Int) -> ()' to '(Int) throws -> Void' loses global actor 'MainActor'
}
```
NOTE: this implementation is a bit gross in that the constraint solver
might emit false warnings about casts it introduced that are actually
safe. This is mainly because closure isolation is only fully determined
after constraint solving. See the FIXME's for more details.
resolves rdar://94462333
Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-`@Sendable`-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.
Fixes the spurious warning from
https://github.com/apple/swift/issues/59910.
In an async context, trying to pass a non-`@Sendable` function to an `@Sendable` parameter or trying to assign a `@MainActor` method to a non-`@MainActor`-typed variable were hard errors. We now think that this a mistake for `@preconcurrency` APIs in Swift 5 mode, as it hinders retroactive adoption of `@Sendable` and `@MainActor` by libraries.
This PR weakens these errors to warnings *only* when the decl which contains the attribute in its type signature is `@preconcurrency` and *only* when in Swift 5 mode (with or without -warn-concurrency). For non-`@preconcurrency` decls, it is still an error.
Fixes <rdar://88703266>.
Introduce the `@preconcurrency` attribute name for `@_predatesConcurrency`,
which has been the favored name in the pitch thread so far. Retain the
old name for now to help smooth migration.
The main effect of this change is that diagnostics about Sendable
conformances now follow the same minimal/full logic used for other
Sendable diagnostics, rather than having their own separate
computation.
These have been subsumed by @_predatesConcurrency. Leave in minimal
parser support that warns about the removal, so we don't fully break
existing source code.
When the Error and CodingKey protocols introduced their Sendable
requirements, we carved out special Sendable checking rules that
suppressed diagnostics when a type becaming Sendable implicitly via
conformance to Error or CodingKey. Extend that logic to any protocol
that predates concurrency, so that existing libraries can benefit from
the same staging we used for Error and CodingKey.
In the future, we can mark Error and CodingKey to eliminate the
special case.
Introduce the `@_predatesConcurrency` attribute, which specifies that a
given declaration existed prior to the introduction of Swift
Concurrency, has been updated to use concurrency features (global
actors, Sendable, etc.), but should retain its pre-concurrency behavior
for clients that have not yet opted into concurrency.
Implement type and actor-isolation adjustments to
`@_predatesConcurrency` declarations to subsume the `@_unsafeMainActor`,
`@_unsafeSendable`, and `@MainActor(unsafe)` use cases. This is the
bulk of the semantic transformations needed for this new attribute,
but is not yet complete.
Part of rdar://84448438.