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.
(cherry picked from commit 629e208970)
When `NonisolatedNonsendingByDefault` is enabled it should infer
`nonisolated(nonsending)` for both async functions and storage as
specified by the proposal.
(cherry picked from commit 8a9bbd5114)
Otherwise, we break memory safety by accessing a generic parameter that does not
exist resulting in undefined behavior.
rdar://150351351
(cherry picked from commit fb3c710212)
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
(cherry picked from commit 1f2107f357)
Suppose protocol P has a primary associated type A, and we have
a `any P<S>` value. We form the generalization signature <T>
with substitution map {T := S}, and the existential signature
<T, Self where T == Self.A>.
Now, if we call a protocol requirement that takes Self.A.A.A,
we see this is fixed concrete type, because the reduced type of
Self.A.A.A is T.A.A in the existential signature.
However, this type parameter is not formed from the
conformance requirements of the generalization signature
(there aren't any), so we cannot directly apply the outer
substitution map.
Instead, change the outer substitution conformance lookup
callback to check if the reduced type parameter is valid
in the generalization signature, and not just rooted in a
generic parameter of the generalization signature.
If it isn't, fall back to global conformance lookup.
A better fix would introduce new requirements into the
generalization signature to handle this, or store them
separately in the generic environment itself. But this is fine
for now.
- Fixes https://github.com/swiftlang/swift/issues/79763.
- Fixes rdar://problem/146111083.
Similar to what we do for 'throws' checking, perform argument-specific
checking for unsafe call arguments. This provides more detailed failures:
```
example.swift:18:3: warning: expression uses unsafe constructs but is not
marked with 'unsafe' [#StrictMemorySafety]
16 | x.f(a: 0, b: 17, c: nil)
17 |
18 | x.f(a: 0, b: 17, c: &i)
| | `- note: argument 'c' in call to instance
method 'f' has unsafe type 'UnsafePointer<Int>?'
| `- warning: expression uses unsafe constructs but is not marked
with 'unsafe' [#StrictMemorySafety]
19 | unsafeF()
20 | }
```
It also means that we won't complain for `nil` or `Optional.none`
arguments passed to unsafe types, which eliminates some false
positives, and won't complain about unsafe result types when there is
a call---because we'd still get complaints later about the
actually-unsafe bit, which is using those results.
Fixes rdar://149629670.
(cherry picked from commit ee9487b86f)
When we look through a "self" application while decomposing a function
call in effects checking, keep track of whether we did so. Use this to
ensure that we get the right parameter types when looking at the
"self" application vs. the outer call.
This has always been wrong, but the async/throws effects don't ever
matter for the innermost application (i.e., for `x.m`), so the
inconsistency didn't come up.
(cherry picked from commit 0b264e2d55)
`getType` here can return a null type if the queried expression isn't
part of the solution, which can currently happen for code completion.
I'm working on a more principled fix for this, but until then this is
a low-risk fix that will unblock the stress tester and can be
cherry-picked to 6.2.
rdar://149759542
In b30006837e, I changed the `if`
condition here to check for the absence of type variables as well
as type parameters. This is incorrect; the type variables come up
in ValueWitnessRequest, and the type parameters come up in
associated type inference. We want the matching to be more lax
in the former case.
Fixes rdar://149438520.
In strict concurrency mode some calls could reference a declaration that
is wrapped in one or more function conversion expressions to apply
concurrency related attributes or erase them (such as `@Sendable` or
`@MainActor`). This shouldn't impact constness checking and the checker
should look through such conversions.
Resolves: rdar://148168219
(cherry picked from commit b484e9645d)
When `MemberImportVisibility` is enabled and a declaration from a cross import
overlay is diagnosed because it has not been imported, suggest imports of the
declaring and bystanding modules instead of the cross import overlay module
(which is an implementation detail).
Resolves rdar://149307959.
This is behavior pre-SE-0461 which is the safest option instead
of inferring `nonisolated(nonsending)` and changing the calling
convention and foregoing Sendable checking.
(cherry picked from commit c25d2fab50)
These functions already have special code generation that keeps them
in the caller's isolation context, so there is no behavior change here.
Resolves: rdar://145672343
(cherry picked from commit 07bad98f6d)
When determining whether a nested type is safe, don't consider whether
its enclosing type is safe. They're independent.
(cherry picked from commit 8ec52c825c)
Always infer `nonisolated(nonsending)` from context directly on
a closure unless the closure is marked as `@concurrent`, otherwise
the closure is not going to get correct isolation and going to hop
to the wrong executor in its preamble.
Resolves: rdar://149107104
(cherry picked from commit 3de72c5452)
The original check examined only the immediate closure, but it's
possible that the closure happens to be in a preconcurrency context
which also requires a downgrade.
Resolves: rdar://148996589
(cherry picked from commit cad2df3d5c)
Downgrade to a warning until the next language mode. This is
necessary since we previously missed coercing macro arguments to
parameter types, resulting in cases where closure arguments weren't
being treated as `async` when they should have been.
rdar://149328745
Don't bind references to storage to use (new ABI) coroutine accessors
unless they're guaranteed to be available. For example, when building
against a resilient module that has coroutine accessors, they can only
be used if the deployment target is >= the version of Swift that
includes the feature.
rdar://148783895
Several callers of `AbstractStorageDecl::getAccessStrategy` only cared
about whether the the access would be via physical storage. Before
adding more arguments to `getAccessStrategy` for which such callers
would have to pass a sentinel value, add a convenience method for this.
