Introduction of `@concurrent` attribute caused an unintended
side-effect in `ClosureEffectsRequest` since the attribute
could only be used on `async` types setting `async` too early
prevented body analysis for `throws` from running.
Resolves: rdar://151421590
SILGen expects actor instance isolation to always come from captures,
we need to maintain that with implicit isolation capture performed by
`@_inheritActorContext(always)`.
Skipping type-checking the body when the preamble fails to type-check
seems to be more of a historical artifact than intentional behavior.
Certain elements of the body may still get type-checked through
request evaluation, and as such may introduce autoclosures that won't
be properly contextualized.
Make sure we continue type-checking the body even if the preamble
fails. We already invalidate any variables bound in the element
pattern, so downstream type-checking should be able to handle it
just fine. This ensures autoclosures get contextualized, and that
we're still able to provide semantic diagnostics for other issues in
the body.
rdar://136500008
This broke when we split `@execution(...)` into `@concurrent` and
`nonisolated(nonsending)` because the latter became its own `TypeRepr`,
whereas the condition for whether to attempt migration diagnostics
inside `resolveASTFunctionType` is still based on the function type's
attributes alone.
By default (currently) the closure passed to a parameter with `@_inheritActorContext`
would only inherit isolation from `nonisolated`, global actor isolated or actor
context when "self" is captured by the closure. `always` changes this behavior to
always inherit actor isolation from context regardless of whether it's captured
or not.
Use the higher level APIs on SourceManager that handle locations in
parent vs child buffers. This then allows us to fix `walkToDeclPre`
such that we don't set the found DeclContext unless the location is
actually within that decl (here the location may well be in a
separate buffer as we may have a replaced function body).
Using IncludeTree::FileList to concat the include tree file systems that
are passed on the command-line. This significantly reduce the
command-line size, and also makes the cache key computation a lot
faster.
rdar://148752988
There's a synthesized call to unsafeBitCast(_:to:), which is obvious
unsafe, and is being diagnosed as such. The compiler generates this
call, so have the compiler also generate the `unsafe` around it to
suppress these warnings.
Fixes rdar://151199011.
Per SE-0411, we compute the isolation of a default value expression
based on what isolation it requires. Include isolated conformance
checks in this computation, rather than always emitting diagnostics,
so that the combination of isolated default values + isolated
conformances works as expected.
Fixes rdar://150691429.
While building an initializer call the declaration reference
should have the same implicitness as the call when it doesn't
require thunking, otherwise don't attempt to mark autoclosures
as non-implicit because it could break assumptions elsewhere.
If a type in an `@_implements` attribute failed to resolve, Sema would assume it was because the type existed but wasn’t a protocol, even if there was another reason for the problem (such as the type not existing). Explicitly resolve the TypeRepr again through a path that will produce diagnostics.
When defaulting to main-actor isolation, types that have synthesized
conformances (e.g., for Equatable, Hashable, Codable) were getting
nonisolated members by default. That would cause compiler errors
because the conformances themselves defaulted to main-actor isolation
when their types were.
Be careful to only mark these members as 'nonisolated' when it makes
sense, and leave them to get the isolation of their enclosing type
when the conformance might have isolation. This ensures that one can
use synthesis of these protocols along with default main-actor mode.
There is a one-off trick here to force the synthesized CodingKeys to
be nonisolated, because the CodingKey protocol requires Sendable.
We'll separately consider whether to generalize this rule.
More of rdar://150691429.
Perform `Sendable` checking on parameter/result of the function
type when conversion between asynchroneous functions results in
a loss of global actor isolation attribute because access would
result in data crossing an isolation boundary.
This is a warning until Swift language mode 6.
Resolves: rdar://130168104
Our logic for doing the "declaration reference" classification was
unnecessarily convoluted, and did "unsafe" classification twice for
properties and subscripts that have other effects (throws/async) on
their getters. Simplify it.
This adds an `appendInterpolation` overload to
`DefaultStringInterpolation` that includes a parameter for providing a
default string when the value to interpolate is `nil`. This allows this
kind of usage:
```swift
let age: Int? = nil
print("Your age is \(age, default: "timeless")")
// Prints "Your age is timeless"
```
The change includes an additional fixit when optional values are
interpolated, with a suggestion to use this `default:` parameter.
Static member referenced were marked as `@Sendable` by `InferSendableFromCaptures`
because metatypes used to be always Sendable which is no longer the case, so in
order to maintain the source compatibility we need to downgrade missing `@Sendable`
to a warning for unapplied static member references.
This affects primarily operators at the moment because other static members
form a curry thunk with a call inside and would be diagnosed as a capture.
Resolves: rdar://150777469
For macro definition checking, we use the range of the `macro`
declaration and re-parse it with `SwiftParser`. Previously it uses the
range including the attributes, but that can result invalid code because
the attribute can be in a `#if ... #endif` region.
Since we don't use attributes for checking the definition, just use the
range without the attributes instead.
rdar://150805795
Some notes:
1. In most cases, I think we were getting lucky with this by just inferring the
closure's isolation from its decl context. In the specific case that we were
looking at here, this was not true since we are returning from an @concurrent
async function a nonisolated(nonsending) method that closes over self. This
occurs since even when NonisolatedNonsendingByDefault we want to start importing
objc async functions as nonisolated(nonsending).
2. I also discovered that in the ActorIsolationChecker we were not visiting the
inner autoclosure meaning that we never set the ActorIsolation field on the
closure. After some discussion with @xedin about potentially visiting the
function in the ActorIsolationChecker, we came to the conclusion that this was
likely to result in source stability changes. So we put in a targeted fix just
for autoclosures in this specific case by setting their actor isolation in the
type checker.
3. Beyond adding tests to objc_async_from_swift to make sure that when
NonisolatedNonsendingByDefault is disabled we do the right thing, I noticed that
we did not have any tests that actually tested the behavior around
objc_async_from_swift when NonisolatedNonsendingByDefault is enabled. So I added
the relevant test lines so we can be sure that we get correct behavior in such a
case.
rdar://150209093
