This diagnostic was staged in
https://github.com/swiftlang/swift/pull/38991 as a warning to not break
source. Give it a reasonable margin and, in turn, convey that it is in
fact a compatibility warning and will become an error.
Check for unsafe conformances for type erasure and opaque type
erasure.
This also uncovered an issue where we were making every conformance of
an unsafe type to an unsafe protocol @unsafe implicitly, even though
that's not really what we want.
AvailableAttr::Kind and AvailabilityDomain are designed to replace
PlatformAgnosticAvailabilityKind, allowing AvailableAttr to more flexibly model
availability for arbitrary domains. For now, the new constructor just
translates its inputs into inputs for the existing constructor. Once all of the
callers of the existing AvailableAttr constructor have been updated to use the
new constructor, the representation of AvailableAttr will be updated to store
the new properties.
Recently I found a soundness hole here, where we would allow conversion
between `any P<T>` and `any Q<T>` even if P and Q have different primary
associated types.
However, the fix was too strict, because we still want to allow the
conversion when the associated types have the same name.
Fixes rdar://141968103.
Introduce an `unsafe` expression akin to `try` and `await` that notes
that there are unsafe constructs in the expression to the right-hand
side. Extend the effects checker to also check for unsafety along with
throwing and async operations. This will result in diagnostics like
the following:
10 | func sum() -> Int {
11 | withUnsafeBufferPointer { buffer in
12 | let value = buffer[0]
| | `- note: reference to unsafe subscript 'subscript(_:)'
| |- warning: expression uses unsafe constructs but is not marked with 'unsafe'
| `- note: reference to parameter 'buffer' involves unsafe type 'UnsafeBufferPointer<Int>'
13 | tryWithP(X())
14 | return fastAdd(buffer.baseAddress, buffer.count)
These will come with a Fix-It that inserts `unsafe` into the proper
place. There's also a warning that appears when `unsafe` doesn't cover
any unsafe code, making it easier to clean up extraneous `unsafe`.
This approach requires that `@unsafe` be present on any declaration
that involves unsafe constructs within its signature. Outside of the
signature, the `unsafe` expression is used to identify unsafe code.
We previously missed diagnosing this for macro
args, fixing it turned out to be a bit more source
breaking than initially thought though, so downgrade
to a warning until Swift 7.
rdar://141963700
Resetting score to `0.1` is intended to make sure that the
solver picks the outermost disjunction in literal chains like
`1 + 2 + 3 ...` because that would provide context to the
inner choices.
Resolves: https://github.com/swiftlang/swift/issues/78371
Resolves: rdar://142105691
Otherwise, we'll in turn complain if the nonisolated lazy property was
@objc. This is also invalid, but the goal here is to avoid the source
break until -swift-version 6.
Fixes rdar://141967932.
`any Sendable` -> `Any` in generic argument positions should be
supported for l-value and inout types as well otherwise it won't
be possible to call setters and mutating methods.
If type equality check fails we need to check whether the types
are the same with deep equality restriction since `any Sendable`
to `Any` conversion is now supported in generic argument positions
of @preconcurrency declarations. i.e. referencing a member on
`[any Sendable]` if member declared in an extension that expects
`Element` to be equal to `Any`.
