Correct several behaviors of availability checking in unavailable contexts that
were inconsistent with the checking model:
- Avoid diagnosing unintroduced and obsolted declarations in contexts that are
unavailable in the same domain.
- Diagnose unavailability normally in type signature contexts.
Get rid of the boolean arguments for unavailability in AvailabilityQuery's
constructors and introduce a `asUnavailable()` modifier that can be used
instead in the contexts where unavailability is relevant.
Conditionally available opaque return types should support availability
conditions that are evaluated in any availability domain. Update
`ConditionallyAvailableSubstitutions` to model its conditions with
`AvailabilityQuery` instead of assuming that conditions are always a single
version query for the current platform.
The availability of isolated deinits were being misdiagnosed for nominal types
that were available prior to the module's deployment target when
`-target-min-inlining-version` was specified. Only the body of an isolated
deinit uses runtime functionality that requires a minimum runtime version, so
availability must be checked in the context of the body of the deinit, not the
interface of the deinit.
Resolves rdar://157563752.
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
If the base type is composed with marker protocol(s) i.e.
`<<Type>> & Sendable`, let's skip this check because such
compositions are always opened and simplified down to a
superclass bound post-Sema.
Resolves: rdar://148782046
`return` statement withot an expression automatically gets an
implicit `()` which is allowed to be converted to types like
`()?` and `Any` or `Any?`. Let's remove a too strict assertion
that expected a contextual type to always be `()?` even
through in reality any type that `()` is convertible to is valid.
Resolves: rdar://152553143
Updates existing diagnostic handling to look through function
conversions when suppressing diagnostics for unused functions that are
return values from callees marked with @discardableResult.
Only warn in `.swiftinterface` files since there may be existing resilient
libraries that were built with this mistake previously.
Resolves rdar://157318951.
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
Since parameters that have function types don't participate in
ranking, function types that are wrapped in optionals should be
excluded as well, because it's possible to overload on that and
such overloads with optional types would gain an undue advantage.
For example:
```
func test(_: (() -> Void)?) {}
func test(_: () -> Void) {}
func compute(handler: () -> Void) {
test(handler)
}
```
Without this change the second overload would be ignored and
the first one would be an exact match.
Resolves: rdar://157234317
Previously we would incorrectly attempt to treat a nested dynamic member
lookup for a subscript as a member reference. Fix `isSubscriptMemberRef`
such that we treat it as a subscript reference.
Fix "affected" declaration computation to handle situations when
a generic type happens to be in a closure parameter position.
Resolves: rdar://150068895
There is no debug output from the `CompareDeclSpecializationRequest`
because the flag that enables it is not passed down from the primary
constraint system.
Such references used to be downgraded until Swift 6 but since the
context is `@preconcurrency` it should be possible for API authors
to introduce concurrency annotations such as `@Sendable` without
breaking clients even when they are compiled in Swift 6 mode.
Resolves: rdar://157061896
This makes sure that optional and non-optional types are ranked
uniformly when matched against a generic parameter type that
could accept either of them.
This is a more general fix for https://github.com/swiftlang/swift/pull/83365
Since this is a source breaking change, downgrade the diagnostic to a warning
until the next language version unless library evolution is enabled, in which
case this would have resulted in a broken `.swiftinterface` and it therefore
makes sense to diagnose eagerly.
Resolves rdar://156919010.
The constraint solver does not reliably give closures a function type
that includes `nonisolated(noncaller)`, even when the immediate context
requires a conversion to such a type. We were trying to work around this
in SILGen, but the peephole only kicked in if the types matched exactly,
so a contextual conversion that e.g. added `throws` was still emitting
the closure as `@concurrent`, which is of course the wrong semantics.
It's relatively easy to avoid all this by just rewriting the closure's
type to include `nonisolated(nonsending)` at a point where we can reliably
decide that, and then SILGen doesn't have to peephole anything for
correctness.
Fixes rdar://155313349
Previously dynamic member subscript wasn't allowed to use `& Sendable`,
since this restriction was lifted the argument cannot simply assume
the parameter type any longer, the key path captures have to be checked
to determine whether it could be marked as Sendable or not.
Resolves: https://github.com/swiftlang/swift/issues/77105
Resolves: rdar://138227393
