Propagate `LeaveClosureBodyUnchecked` flag from `typeCheckASTNodeAtLoc`
down to declaration checker to skip checking closures associated with
pattern binding entry initializers. This is no-op until multi-statement
inference becomes enabled by default.
Closure result type or generic parameter associated with such a location
could bw inferred from a body of a multi-statement closure (when inference
is enabled), so we need to give closure a chance to run before attemtping
a hole for such positions in diagnostic mode.
When multi-statement closure inference is enabled it's body is
type-checked together with enclosing context, so they could be
walked directly just like single-expressions ones.
While building a closure to inject `checkExpect` code, clone member
references associated with assignment. Re-using AST nodes is generally
invalid. This is visible with multi-statement closure inference enabled,
because the body is type-checked together with enclosing context
and both elements end up sharing `DeclRefExpr` and `MemberRefExpr`s.
Improve the equality check for actor isolation to prevent differences
between "unsafe" global actor and global actor isolation from causing
inequality. The operation here is about conceptual equality, not
precise storage semantics. This allows us to simplify override
isolation checking and, likely, other places I haven't seen yet.
This change was originally introduced in https://github.com/apple/swift/pull/36752.
The problem occurs in the following scenario:
- New compiler with this change is used to build a dylib and swiftinterface
file for module A, which defines a RawRepresentable enum type E.
- Module B imports module A and references == on two E instances.
- The module B is run against a dylib of module A built with the old compiler.
At this point, module B will not link (or run) because the symbol for E.==
is not present in the old dylib for A.
The only real solution here is to disable this new optimization when
building a module for -enable-library-evolution, unfortunately.
In the future, we could make the derived E.== symbol @_alwaysEmitIntoClient.
However today, synthesized declarations cannot be @_alwaysEmitIntoClient
because they do not have source text that can be emitted into the
swiftinterface file. One day, we might gain the ability to print Exprs as
source text that parses back in, at which point we could allow synthesized
declarations to be @_alwaysEmitIntoClient.
Fixes rdar://problem/84912735 and rdar://problem/82919247.
This ensures, among other things, that `@_predatesConcurrency` doesn't
affect the types of entities anywhere in a module compiled in Swift 6, so
we get stricter checking throughout.
When in "existing" Swift code that is Swift 5.x and has not adopted
concurrency, allow mismatches in function types that only involve
ABI-neutral concurrency changes (e.g., adding `@Sendable` or removing
a global actor) by downgrading the diagnostic to a warning. This
improves the story for incremental adoption of concurrency in an
existing code base.
As part of this, generalize the facility for downgrading an error to a
warning when performing diagnostics in the constraint solver, using the
new diagnostic behavior limits rather than duplicating diagnostics.
When checking the viability of an original function candidate as specified in a `@derivative` attribute, a candidate's signautre can have more generic requirements than the required signature. Such cases need to be checked and diagnosed.
Resolves SR-15530 / rdar://85845512.
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.
Determine whether a particular missing Sendable diagnostic should be
emitted as a warning or error, or even ignored entirely, based on the
emerging rules from the proposal for incremental adoption of Sendable
checking.
Instead of tracking the single-expression closures in a separate
structure and passing that in under the right conditions, it makes more
sense to simply set the 'Where' decl context to the single-expr closure
and use the correct declaration context to determine whether the context
is async. The reduces the number of variables that need to get plumbed
through to the actual unavailable-from-async check and simplifies the
actual check from figuring out whether we're in a single-expr closure or
in an async context.
The core part of the check runs as follows
1. Are we in an async context
2. Does the decl we're calling have the unavailableFromAsync attribute
3. Emit a diagnostic
There are a couple challenges that muddy the implementation. First,
single-expression closures are typechecked differently than
multi-expression closures. The single-expression closure is never added
to the closure stack. We have to record it separately upon entry to
verify separately. This is necessary for `_ = { foo() }()` where `foo`
is unavailable from async, and the surrounding context is async.
The second challenge is regarding when things get typechecked. A type
must be assigned to AbstractClosureExprs to determine whether they are
an async context or not. Unfortunately, availability checking runs
before types are fully assigned in some cases. This specifically happens
when working with result builders in specific conditions. I haven't been
able to figure out how to reduce the issue further.
