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
If an overridden decl requires an underscored accessor, then the derived
decl requires one too. Otherwise dispatch to a less-derived instance
could bind to the underscored accessor which lacks an override.
rdar://149352777
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
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
Previously we would avoid rewriting the arguments in CSApply, but
that can result in incorrect behavior in MiscDiagnostics passes, e.g
incorrectly treating all closure arguments as escaping. Make sure
we rewrite the arguments as we would in regular type-checking.
rdar://148665502
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.
