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
This request was looking through to the root conformance, which could
mess with the caching bits. Sink the "is nonisolated conformance" bit
down into ProtocolConformance, and have the request for a non-root
conformance be defined in terms of the request for the root
conformance.
If all of the witnesses to a conformance are nonisolated, then infer that
conformance as nonisolated rather than global-actor-isolated. This is
only relevant when InferIsolatedConformances is enabled, and prevents
that inference to help maintain source compatibility.
Just like `@preconcurrency` for concurrency, this attribute is going
to allow exhaustiveness error downgrades for enums that were retroactively
marked as `@extensible`.
per SE-0431, function conversions from an @isolated(any) function to a synchronous,
non-@isolated(any) function type should not be allowed. this adds a warning during
type checking to enforce this, which will be an error in a future major
language mode.
When `NonisolatedNonsendingByDefault` is enabled it should infer
`nonisolated(nonsending)` for both async functions and storage as
specified by the proposal.
It is possible for a C++ class template to inherit from a specialization
of itself. Normally, these are imported to Swift as separate (unrelated)
types, but when symbolic import is enabled, unspecialized templates are
imported in place of their specializations, leading to circularly
inheriting classes to seemingly inherit from themselves.
This patch adds a check to guard against the most common case of
circular inheritance, when a class template directly inherits from
itself. This pattern appears in a recent version of libc++,
necessitating this patch. However, the solution here is imperfect as it
does not handle more complex/contrived circular inheritance patterns.
This patch also adds a test case exercising this pattern. The
-index-store-path flag causes swift-frontend to index the C++ module
with symbolic import enabled, without the fix in this patch, that test
triggers an assertion failure due to the circular reference (and can
infinitely recurse in the StorageVisitor when assertions are disabled).
rdar://148026461
Instead of passing in the substituted type, we pass in the
InFlightSubstitution. This allows the substituted type to be
recovered if needed, but we can now skip computing it for
the common case of LookUpConformanceInSubstitutionMap.
