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
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.
isolation checker.
Previously, the actor isolation checker would crash when attempting to
mark an operator call as implicitly async, because it was specifically
expecting to see a CallExpr. Instead, accept all ApplyExprs except for
SelfApplyExpr.
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
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.
When checking for the sendability in a call, use the sendability of the
original argument expressions rather than the parameter type, looking
through any implicit conversions that might remove `Sendable`.
Fixes rdar://110763694 / FB12343467.
Isolation checking for calls had two separate implementation places:
one that looked at the declaration being called (for member
declarations) and one that worked on the actual call expression. Unify
on the latter implementation, which is more general and has access to
the specific call arguments. Improve diagnostics here somewher so we
don't regress in that area.
This refactoring shouldn't change the actual semantics, but it makes
upcoming semantic changes easier.
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
Instead of the `warning` Boolean threaded through the solver's
diagnostics, thread `DiagnosticBehavior` to be used as the behavior
limit. Use this for concurrency checking (specifically dropped
`@Sendable` and dropped global actors) so the solver gets more control
over these diagnostics.
This change restores the diagnostics to a usable state after the prior
change, which introduced extra noise. The only change from existing
beavior is that dropping a global actor from a function type is now
always a warning in Swift < 6. This is partly intentional, because
there are some places where dropping the global actor is well-formed.
There were some tests that relied on the top-level code not being an
asynchronous context to emit certain error messages. Now that it is,
those tests weren't emitting the expected error message.
In other cases, the issue was that they were trying to initialize a
global variable and weren't really using top-level code as top-level
code, so adding `-parse-as-library` was sufficient for the testing
purposes.
To fix the objc_async test, parsing as a library was nearly sufficient.
Unfortunately, the little `if #available` trick that I was using stopped
working since it relied on being in top-level code. So that we emit the
unavailableFromAsync error message, I had to set the availability on
everything correctly because we can't just disable availability
checking.
Extend the diagnostics for `Sendable` conformances to always diagnose
missing `Sendable` conformances for nominal types that are within the
same module. The intuition here is that if the type is in the same
module, it can be updated and evaluated at the same time as code
requiring the `Sendable` conformance is introduced.
Another part of rdar://78269348.
Rework Sendable checking to be completely based on "missing"
conformances, so that we can individually diagnose missing Sendable
conformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if either the module where the non-Sendable type
was declared or the module where it was checked was compiled with a
mode that consistently diagnoses `Sendable`, either by virtue of
being Swift 6 or because `-warn-concurrency` was provided on the
command line. And have that diagnostic be an error in Swift 6 or
warning in Swift 5.x.
There is much tuning to be done here.
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.
Check actor isolation of calls to functions with global-actor-qualified
type. This closes a pre-existing loophole where a value of
global-actor-qualified function type could be called from any context.
Paired with this, references to global-actor-qualified function
declarations will get global-actor-qualified function type whenever
they are referenced within an experience, i.e., whenever we form a
value of that type. Such references can occur anywhere (one does not
need to be on the actor), and carrying the global actor along with the
function type ensures that they can only be called from the right
actor. For example:
@MainActor func onlyOnMainActor() { ... }
func callIt(_ fn: @MainActor () -> Void) {
fn() // error: not on the main actor, so cannot synchronously call
// this wasn't previously diagnosed
}
func passIt() {
callIt(onlyOnMainActor) // okay to pass the function
// used to be an error
}
While here, fix up some broken substitution logic for
global-actor-qualified function types and "override" actor isolation.
When referencing a function that is on a global actor, e.g.,
@MainActor func doSomething() -> Int
the result of that reference is a global-actor-qualified function type, e.g.,
@MainActor () -> Int
Part of rdar://76030136.
We now mark some DeclRefExpr and LookupExprs as implicitly async
during typechecking, depending on whether they appear in a context
that is only performing a read / get operation, and whether they
are cross-actor operations.
also resolves rdar://72403401 by improving the error messages
(no more vague "'await' in async context" when its clearly a call!)
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
Currently, we don't have a fix-it to insert 'async', so I've marked those places
as not expecting a fix-it, until someone goes and implements that (rdar://72313654)
