The `@unchecked` conformance is effectively the same as
`@safe(unchecked)`, in that it asserts memory safety in a place where
it cannot be automatically checked. But once that has been asserted,
there is no reason to diagnose anywhere else.
While here, drop the "unsafe declaration here" note, which isn't
adding value but did add noise.
Thanks, Alex!
Protocol conformances have a handful attributes that can apply to them
directly, including @unchecked (for Sendable), @preconcurrency, and
@retroactive. Generalize this into an option set that we carry around,
so it's a bit easier to add them, as well as reworking the
serialization logic to deal with an arbitrary number of such options.
Use this generality to add support for @unsafe conformances, which are
needed when unsafe witnesses are used to conform to safe requirements.
Implement general support for @unsafe conformances, including
producing a single diagnostic per missing @unsafe that provides a
Fix-It and collects together all of the unsafe witnesses as notes.
@preconcurrency imports disable Sendable checking, which can lead to
data races that undermine memory safety. Diagnose such imports, and
require `@safe(unchecked)` to suppress the diagnostic.
Under strict concurrency and memory safety, uses of `@unchecked
Sendable` conformances are considered unsafe. Diagnose the use sites,
not the declaration site.
A `@backDeployed` function printed in a `.swiftinterface` must have a function
body so that SILGen can emit a fallback copy to call when the back deployed
function is unavailable. Previously, the compiler would crash in SILGen when
compiling an interface containing a back deployed function without a body.
Resolves rdar://141593108.
A nonisolated(unsafe) declaration clearly indicates that the
declaration itself is unsafe, so it doesn't need to be diagnosted.
Instead, diagnose any reference to such a declaration that occurs
when strict concurrency is enabled. Make this a collatable unsafe use.
Drive the strict-safety diagnostics for a particular declaration from
primary type checking for declarations, so any memory-safety-related
diagnostics will only be emitted for the primary files. This also
brings them together as notes under a single warning for each
declaration.
Instead of producing a warning for each use of an unsafe entity,
collect all of the uses of unsafe constructs within a given function
and batch them together in a single diagnostic at the function level
that tells you what you can do (add `@unsafe` or `@safe(unchecked)`,
depending on whether all unsafe uses were in the definition), plus
notes identifying every unsafe use within that declaration. The new
diagnostic renderer nicely collects together in a single snippet, so
it's easier to reason about.
Here's an example from the embedded runtime that previously would have
been 6 separate warnings, each with 1-2 notes:
```
swift/stdlib/public/core/EmbeddedRuntime.swift:397:13: warning: global function 'swift_retainCount' involves unsafe code; use '@safe(unchecked)' to assert that the code is memory-safe
395 |
396 | @_cdecl("swift_retainCount")
397 | public func swift_retainCount(object: Builtin.RawPointer) -> Int {
| `- warning: global function 'swift_retainCount' involves unsafe code; use '@safe(unchecked)' to assert that the code is memory-safe
398 | if !isValidPointerForNativeRetain(object: object) { return 0 }
399 | let o = UnsafeMutablePointer<HeapObject>(object)
| | `- note: call to unsafe initializer 'init(_:)'
| `- note: reference to unsafe generic struct 'UnsafeMutablePointer'
400 | let refcount = refcountPointer(for: o)
| | `- note: reference to let 'o' involves unsafe type 'UnsafeMutablePointer<HeapObject>'
| `- note: call to global function 'refcountPointer(for:)' involves unsafe type 'UnsafeMutablePointer<Int>'
401 | return loadAcquire(refcount) & HeapObject.refcountMask
| | `- note: reference to let 'refcount' involves unsafe type 'UnsafeMutablePointer<Int>'
| `- note: call to global function 'loadAcquire' involves unsafe type 'UnsafeMutablePointer<Int>'
402 | }
403 |
```
Note that we have lost a little bit of information, because we no
longer produce "unsafe declaration was here" notes pointing back at
things like `UnsafeMutablePointer` or `recountPointer(for:)`. However,
strict memory safety tends to be noisy to turn on, so it's worth
losing a little bit of easily-recovered information to gain some
brevity.
What’s implemented now is actually *far* more thorough than what the surface syntax can currently express, mainly because I can’t apply @abi to nominal types yet.
Check for:
• Matching decl kinds
• Matching PBD shapes (does every VarDecl on both sides have a counterpart?)
• Matching function effects
• Matching function arity (roughly)
Sema now type-checks the alternate ABI-providing decls inside of @abi attributes.
Making this work—particularly, making redeclaration checking work—required making name lookup aware of ABI decls. Name lookup now evaluates both API-providing and ABI-providing declarations. In most cases, it will filter ABI-only decls out unless a specific flag is passed, in which case it will filter API-only decls out instead. Calls that simply retrieve a list of declarations, like `IterableDeclContext::getMembers()` and friends, typically only return API-providing decls; you have to access the ABI-providing ones through those.
As part of that work, I have also added some basic compiler interfaces for working with the API-providing and ABI-providing variants. `ABIRole` encodes whether a declaration provides only API, only ABI, or both, and `ABIRoleInfo` combines that with a pointer to the counterpart providing the other role (for a declaration that provides both, that’ll just be a pointer to `this`).
Decl checking of behavior specific to @abi will come in a future commit.
Note that this probably doesn’t properly exercise some of the new code (ASTScope::lookupEnclosingABIAttributeScope(), for instance); I expect that to happen only once we can rename types using an @abi attribute, since that will create distinguishable behavior differences when resolving TypeReprs in other @abi attributes.
The new `DECL_ATTR_FEATURE_REQUIREMENT` macro in DeclAttr.def can be used to declare that an attribute should only be available when a related language feature is enabled.
Effects:
• `#if hasAttribute(someAttr)` will return `false` unless the required feature is enabled.
• Code completion will not include the attribute unless the required feature is enabled.
• `TypeChecker::checkDeclAttributes()` diagnoses non-implicit uses of the attribute.
Add this mechanism and use it to tie @abi to the ABIAttribute feature. Also design tests for it.
This attribute will allow you to specify an alternate version of the declaration used for mangling. It will allow minor adjustments to be made to declarations so long as they’re still compatible at the calling convention level, such as refining isolation or sendability, renaming without breaking ABI, etc.
The attribute is behind the experimental feature flag `ABIAttribute`.
This convenience returns an optional `SemanticAvailableAttr` (since in the
future, lookup of the `AvailabilityDomain` can fail). It replaces
`Decl::getDomainForAvailableAttr()`, since most callers will need to form a
`SemanticAvailableAttr` with the resulting domain anyways.
This new attribute iterator returned from the query makes it simpler to
implement algorithms that need access to both the `AvailableAttr *` and its
corresponding `AvailabilityDomain`. This is also work towards making it
possible to return an optional `AvailabilityDomain` from
`Decl::getDomainForAvailableAttr()`.
Instead of starting a depth-first search from each type variable
and marking all type variables that haven't been marked yet,
we can implement this as a union-find.
We can also store the temporary state directly inside the
TypeVariableType::Implementation, instead of creating large
DenseMaps whose keys range over all type variables.
