I discovered this while trying to figure out why we were dropping a sending bit
when computing a reabstraction thunk in the tests for the following commit. This
turned out to be the reason why.
Now that AvailableAttr has storage for its cached AvailabilityDomain, it's no
longer necessary to store an AvailabilityDomain inline in
SemanticAvailableAttr.
NFC.
`x declared here` is not helpful and clear enough, especially when there
are other notes attached. Swap it for a new note that says
`requirement x declared here`.
Represent an AvailabilityDomain as a pointer union where one member of the
union is inline storage for built-in domains with known requirements and the
other member of the union is a pointer to an externally allocated domain
definition.
NFC.
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.
It was difficult to preserve the existing, buggy behavior of availability
attribute inference with respect to attributes specifying availability for
non-platform-specific domains. Instead, this change improves attribute merging
by tracking every domain independently, and only merging attributes from the
same domain.
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.
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.
As an example, use this for the "`@preconcurrency` on import has no
effect" warning, which is not yet working correctly. This disables it
by default but leaves it in place for our testing.
