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.
If the opaque generic signature has a same-type requirement between
an outer type parameter and an opaque type parameter, the former
should always precede the latter in the type parameter order, even
if it is longer. Achieve this by giving the innermost generic
parameters a non-zero weight in the opaque generic signature.
Now, when we map a type parameter into an opaque generic environment,
we correctly decide if it is represented by a type parameter of the
outer generic signature, in which case we apply the outer substitution
map instead of instantiating an archetype.
The included test case demonstrates the issue; we declare an opaque
return type `some P<T.A.A>`, so the opaque generic signature has a
requirement `T.A.A == <<some P>>.A`. Previously, the reduced type of
`<<some P>>.A` was `<<some P>>.A`, so it remained opaque; now we
apply outer substitutions to `T.A.A`.
- Fixes https://github.com/swiftlang/swift/issues/81036.
- Fixes rdar://problem/149871931.
Check for unsafe constructs in all modes, so that we can emit the
"unsafe does not cover any unsafe constructs" warning consistently.
One does not need to write "unsafe" outside of strict memory safety
mode, but if you do... it needs to cover unsafe behavior.
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.
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.
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
`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
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.
It has indirect effects on the accessors, so it shouldn’t matter, but we can defensively redirect the query to the API counterpart anyway.
This was the last `InferredInABIAttr` attribute, so we can now remove all of the infrastructure involved in supporting attribute inference.
CustomAttr backs four different features, each of which requires a different behavior in `@abi`:
• Global actors: Permitted (and permitted to vary) since they can affect mangling
• Result builders: Forbidden inside an `@abi` since they have no ABI impact
• Property wrappers: Forbidden both inside an `@abi` and on a decl with an `@abi` since it’s not clear how we would apply `@abi` to the auxiliary decls
• Attached macros: Forbidden inside an `@abi` since an ABI-only decl has no body, accessors, members, peers, extensions, or (currently) conformances
Implement these behaviors (outside of `ABIDeclChecker` since they can’t be described there).
Macro-related tests are not included in this commit; they require matching swift-syntax changes which are being negotiated.
Macro expansions are now treated like a part of the source file they belong to, for purposes of the “second declaration is the one that’s diagnosed” rule. This helps stabilize a behavior that was easy to perturb.
The decl checker was effectively not being run on these because we weren’t typechecking the PBD and typechecking the VarDecl itself is basically a no-op.
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.
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
