Specifically, this code was added because otherwise we would in swift 5 +
strict-concurrency mode emit two warnings, one at the AST level and one at the
SIL level. Once we are in swift-6 mode, this does not happen since we stop
compiling at the AST level since we will emit the AST level diagnostic as an
error.
To do this, we tried to pattern match what the AST was erroring upon and treat
the parameter as disconnected instead of being isolated. Sadly, this resulted in
us treating certain closure cases incorrectly and not emit a diagnostic
(creating a concurrency hole).
Given that this behavior results in a bad diagnostic only to avoid emitting two
diagnostics in a mode which is not going to last forever... it really doesn't
make sense to keep it. We really need a better way to handle these sorts of
issues. Perhaps a special semantic parameter put on the function that squelches
certain errors. But that is something for another day. The specific case it
messes up is:
```
class NonSendable {
func action() async {}
}
@MainActor
final class Foo {
let value = NonSendable()
func perform() {
Task { [value] in
await value.action() // Should emit error but do not.
}
}
}
```
In this case, we think that value is sending... when it isnt and we should emit
an error.
rdar://146378329
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
This was added in #80220 to fix a related issue with captures of packs,
but it's even better to sink this down into diagnoseNonSendableTypes(),
so that we can handle packs in parameter position as well.
- Fixes https://github.com/swiftlang/swift/issues/82614.
- Fixes rdar://problem/154649522.
Adjust the downgrade check for static member references to
account for the fact that argument could come of a tuple or
some other reference that doesn't have a declaration associated
with it.
Resolves: rdar://153083848
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
Add specific deployment target versions to some tests that need to test
10.x-specific behaviours and are currently depending on the default
deployment target.
Certain tests were only checking either the stable or unstable ABI
depending on the platform the test was running. In those cases I doubled
up the checks so that we would test both cases on platforms that
supported it. This might use a bit of extra time on targets that only
support the stable ABI, but it seemed worth it for the additional
coverage in CI.
wording.
Splitting up the diagnostic into separate diagnostics based on the reference
kind is easier for me to read. The wording of the error message now puts
the problem -- crossing an isolation boundary -- at the center of the message,
and attempts to clarify how the value crosses an isolation boundary. E.g. for
the witness diagnostics, the value crosses an isolation boundary when calling
the witness through the protocol requirement in generic code.
This change does not add any additional information to the diagnostics, but it'd
be valuable to show both the source and destination isolation.
Sema's sendable checking is subsumed by the region isolation SIL pass. Now
that region isolation is always enabled under complete concurrency checking,
the code can be deleted from the actor isolation checker. Note that this
removes these diagnostics from targeted concurrency checking. I think it's
better to remove these diagnostics from targeted checking because in many
cases, they're false positive data-race reports that the programmer ultimately
won't have to address. If we want these diagnostics in targeted checking, we
should do it via region isolation.
defining module, and diagnose redundant Sendable conformances.
We still allow re-stating inherited unchecked Sendable conformances in
subclasses because inherited Sendable conformances are surprising when
they opt out of static checking. Otherwise, warning on redundant Sendable
conformances nudges programmers toward cleaning up unnecessary retroactive
Sendable conformances over time as libraries incrementally add the
conformances directly.
in favor of explicit available ones.
The type checker does not support the notion of multiple protocol
conformances; there can only be one conformance, and if that conformance
is unavailable, you cannot specify your own available conformance. This
is important for Sendable checking; if a framework specifies that a type
is explicitly not Sendable with an unavailable Sendable conformance,
clients cannot ignore Sendable violations involving that type. If a
superclass wants to allow subclasses to add a Sendable conformance, it
should not declare an unavailable Sendable conformance.
This fixes a few issues I missed in the past bit of commits.
I need to fix one issue around async let, but I am going to fix it when I do a
sweep across async let.
Change the availability checker to check substitution maps of underlying
values for opaque result types to diagnose unavailable conformances. This
change also makes sure `Sendable` availability diagnostics are errors in
Swift 6 mode.
Sendable derivation was only checking for explicit global actor
attributes. It should also account for inferred global actor
attributes, e.g. from protocol conformances.
subclassing.
These features are additive, and they don't need to be gated behind the
`GlobalActorIsolatedTypesUsability` upcoming feature. The other inference
changes, including `@Sendable` inference for global-actor-isolated function
types, and global-actor inference on protocol refinements, remain gated
behind the upcoming flag.
As part of this I went through how we handled inference and rather than using a
grab-bag getActorIsolation that was confusing to use, I created split APIs for
specific use cases (actor instance, global actor, just an apply expr crossing)
that makes it clearer inside the SILIsolationInfo::get* APIs what we are
actually trying to model. I found a few issues as a result and fixed most of
them if they were small. I also fixed one bigger one around computed property
initializers in the next commit. There is a larger change I didn't fix around allowing function
ref/partial_apply with isolated self parameters have a delayed flow sensitive
actor isolation... this will be fixed in a subsequent commit.
This also fixes a bunch of cases where we were printing actor-isolated instead
of 'self' isolated.
rdar://127295657
as warnings.
Marking the closure parameter to these inits as `@Sendable` changed the
inferred isolation of closure arguments in actor-isolated contexts, which
caused new effects checker errors when accessing isolated properties and
methods without `await`. Mark these `init`s as `@preconcurrency`, and fix
the effects checker to downgrade those errors to warnings when the context
of the call is `@preconcurrency`.
Specifically, I am transforming it from "may cause a race" -> "may cause a data
race". Adding data is a small thing, but it adds a bunch of nice clarity.
I added a disable flag -disable-region-based-isolation-with-strict-concurrency
so that we do not need to update the current tests. It is only available when
asserts are enabled to ensure users cannot use it.
rdar://125918028
I am doing this since it isn't always going to be an access. We may not have
memory. We are talking about uses here!
I was able to just use sed so it was an easy fix.
As an example of the change:
- // expected-note @-1 {{'x' is transferred from nonisolated caller to main actor-isolated callee. Later uses in caller could race with potential uses in callee}}
+ // expected-note @-1 {{transferring disconnected 'x' to main actor-isolated callee could cause races in between callee main actor-isolated and local nonisolated uses}}
Part of the reason I am doing this is that I am going to be ensuring that we
handle a bunch more cases and I wanted to fix this diagnostic before I added
more incaranations of it to the tests.
This is just a pseudo-why are these two things part of the same region error. I
am going to remove this for now and the proper form of this diagnostic will come
back when I land the region history functionality.
