Introduce @unsafe and the ability to prohibit use of unsafe entities
#75413
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci please smoke test |
|
@swift-ci please build toolchain |
|
@swift-ci please smoke test Windows |
|
@swift-ci please build toolchain |
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
|
@swift-ci please build toolchain |
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
DougGregor
requested review from
ktoso,
a team,
AnthonyLatsis,
hborla,
slavapestov,
xedin,
tshortli,
ahoppen,
bnbarham,
CodaFi,
hamishknight,
rintaro,
zoecarver,
hyp,
egorzhdan,
beccadax and
ian-twilightcoder
as code owners
|
@swift-ci please test |
|
@swift-ci please test Linux |
…tions
Allow any declaration to be marked with `@unsafe`, meaning that it
involves unsafe code. This also extends to C declarations marked with
the `swift_attr("unsafe")` attribute.
Under a separate experimental flag (`DisallowUnsafe`), diagnose any
attempt to use an `@unsafe` declaration or any unsafe language feature
(such as `unowned(unsafe)`, `@unchecked Sendable`). This begins to
define a "safe" mode in Swift that prohibits memory-unsafe constructs.
When referencing a declaration, check whether any of the types in that reference are unsafe. This can diagnose cases where the original declaration either wasn't actually unsafe, or is being provided with unsafe types via generics.
Annotate all of the `Unsafe*` types and `unsafe` functions in the standard library (including concurrency, synchronization, etc.) as `@unsafe`. Add a few tests to ensure that we detect uses of these types in clients that have disabled unsafe code.
Warnings fit better with the approach we're going for, and can be escalated to errors by `-warnings-as-errors` for clients that need it.
|
@swift-ci please smoke test |
|
Merging as experimental, details will change |
2 tasks
stmontgomery
added a commit
to swiftlang/swift-testing
that referenced
this pull request
Apr 19, 2025
…ting 6.1 development snapshot toolchains (#1084) This fixes a build failure when attempting to build the `main` branch using a 6.1 development snapshot toolchain. This failure was introduced by #1069, which added usage of the new `@unsafe` attribute, and the failure was revealed when we set up the 6.1 CI jobs in #1083. Here are some relevant related Swift PRs which give context around these changes: - swiftlang/swift#75413 - swiftlang/swift#79645 See the code comment for more details. ### Checklist: - [x] Code and documentation should follow the style of the [Style Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md). - [x] If public symbols are renamed or modified, DocC references should be updated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allow any declaration to be marked with
@unsafe, meaning that it involves unsafe code. This also extends to C declarations marked with theswift_attr("unsafe")attribute.Under a separate experimental flag (
WarnUnsafe), warn about any attempt to use an@unsafedeclaration, type, or any unsafe language feature (such asunowned(unsafe),@unchecked Sendable). This defines a "safe" mode in Swift that prohibits memory-unsafe constructs. These language features are considered unsafe:@unchecked Sendable: diagnosed only when strict concurrency is enabled.unowned(unsafe)nonisolated(unsafe): diagnosed only when strict concurrency is enabled.An
@unsafedeclaration cannot:Annotate all of the
Unsafe*types andunsafefunctions in the standard library (including concurrency, synchronization, etc.) as@unsafe. This includes:Unsafe(Mutable)(Raw)(Buffer)PointerOpaquePointerUnmanagedunsafeBitCast,unsafeDowncastOptional.unsafelyUnwrappedUnsafeContinuation,withUnsafe(Throwing)ContinuationUnsafeCurrentTaskMutex'sunsafeTryLock,unsafeLock,unsafeUnlockVolatileMappedRegister.init(unsafeBitPattern:)There are a large number of APIs that could be explicitly marked
@unsafebecause they traffic in unsafe types. This isn't strictly necessary, because the language design will diagnose attempts to use these entities when in the safe mode, so I've opted to keep the set of changes smaller by omitting them.I'm tracking this idea via rdar://133963224