I want to expose the syntactic checking to other parts of Sema, so that
we can determine whether an expression is a candidate for having a
`consume` added to it.
TLDR: This makes it so that we always can parse sending/transferring but changes
the semantic language effects to be keyed on RegionBasedIsolation instead.
----
The key thing that makes this all work is that I changed all of the "special"
semantic changes originally triggered on *ArgsAndResults to now be triggered
based on RegionBasedIsolation being enabled. This makes a lot of sense since we
want these semantic changes specifically to be combined with the checkers that
RegionBasedIsolation turns on. As a result, even though this causes these two
features to always be enabled, we just parse it but we do not use it for
anything semantically.
rdar://128961672
Computing capture information requires a type checked AST, which we don’t have during code completion. To fix an assertion failure, don’t look for a captured `isolated` parameter while computing a closure’s actor isolation during code completion.
rdar://126923558
Use a switch statement to cover all the possible kinds of condition elements
and implement diagnostics in separate functions for each kind of condition
element.
NFC.
In 5.10 we warned on this:
```swift
func bar(@_implicitSelfCapture _ fn: @escaping () -> Void) {}
class C {
func foo() {
bar { [weak self] in
foo()
}
}
}
```
But with the implicit self rework, this accidentally
became an error. Fix it to ensure we continue to
warn until Swift 6 mode.
rdar://128941797
If the contextual type propagated into the optional chain mismatches with
the inner type formed from its member references and that inner type
is a result of some fix, let's consider that un-salvageable and avoid
producing additional "ignore contextual type" fixes which only lead
to subpar solutions.
If both sides of an `OptionalObject` constraint are un-inferred, their
binding sets need to correctly reflect adjacency - a type variable
that represents optional would get "object" as an adjacency through
its potential binding (the binding is - "object" wrapped in a single
level of optional) and "object" type variable needs to get its parent
optional type variable added to its adjacency list explicitly.
Without this it would be possible to prematurely pick "object" before
its parent optional type variable.
Resolves: https://github.com/apple/swift/issues/73207
Resolves: rdar://126960579
updates noasync diagnostics in TypeCheckAvailability.cpp to diagnose
defer bodies as if they had the same `isAsyncContext()` value as their
nearest non-defer parent scope.
resolves: https://github.com/apple/swift/issues/73614
Due to a missing source location in the implicitly-generated `await` in the
async for loop, we misdiagnosed availability within an `if #available`.
Fixes rdar://128560745.
Checking for the presence of a feature flag in order to allow syntax tends to
result in condfails when applied to `.swiftinterfaces`, since older compilers
that have this restriction may be used to compile newer interfaces where the
restriction has been lifted. Remove this restriction for non-escapable types
when typechecking an interface.
Resolves rdar://128577611
When using shorthand syntax for optional binding,
if the variable we are binding is accessed asynchronously,
provide an insertion fixIt of the form: ' = await (identifier)'.
Previously, we would suggest only adding the 'await'
which resulted in an error since the identifier is required.
VarDecls with `@_projectedValueProperty` have already had the property
wrapper transform applied. This only impacts swiftinterfaces, and if
a swiftinterface was produced against a Concurrency library that does
not declare `TaskLocal` as a macro, we need to ignore the macro to avoid
producing duplicate declarations. This is only needed temporarily until
all swiftinterfaces have been built against the Concurrency library
containing the new macro declaration.
If closure appears inside of a pack expansion, the elements
that reference pack elements have to bring expansion's shape
type in scope to make sure that the shapes match.
Type variable reference collector needs to be augmented to collect
type variables associated with pack expansions that a closure references
elements of, otherwise it would get disconnected from the context.
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`.
When SE-0412 (strict concurrency for global variables) is enabled, each
global or static mutable variable will be diagnosed if it isn't
explicitly on a global actor or `nonisolated(unsafe)`.
Suppress diagnostics for references to such global variables when they
are in the same module as the declaration of the global variable
itself. While these diagnostics are technically correct, they are not
strictly necessary since we've already diagnosed the global variable
itself (with more actionable advice), and they tend to pile on the
developer in a manner that is not helpful.
When diagnosing a concurrency-unsafe global or static variable, provide
Fix-Its with specific guidance and advice. This is intended to aid the
workflow for folks enabling strict concurrency checking or Swift 6.
There are up to three Fix-Its attached to a diagnostic about
concurrency-unsafe global/static variables:
* convert 'global' to a 'let' constant to make the shared state
immutable, which replaces `var` with `let`
* restrict 'global' to the main actor if it will only be accessed from the
main thread, which adds `@MainActor`
* unsafely mark %0 as concurrency-safe if all accesses are protected
by an external synchronization mechanism, which adds `nonisolated(unsafe)`
I fretted over two things before deciding on this path:
1. For the second note, the reality is that any global actor will
suffice, but `@MainActor` is orders of magnitude more common than any
other global actor, so "common case convenience" wins over "precise
but less useful.
2. For the third note, `nonisolated(unsafe)` should only be used
sparingly, and surfacing it via Fix-It could cause overuse. However,
developers need to know about it, and this is how we do that. It comes
last in the list of notes (after the better options) and says "unsafe"
in not one but two places.
When a retroactive conformance to a protocol that inherits from `Sendable`
introduces an implicit `Sendable` conformance, allow `@preconcurrency`
to suppress the diagnostic about the `Sendable` conformance being
introduced outside of the original source file.
Fixes rdar://125080066.
The "send non-Sendable" pass had a copy of the code for determining
what limit to put on the diagnostic behavior for a given reference to
a nominal type declaration. Rather than update that copy for the
recent changes to the canonical version of this in the type checker,
share the computation.
