Skip to content

Implement an unsafe expression to cover uses of unsafe constructs #78554

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jan 11, 2025

Conversation

DougGregor
Copy link
Member

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.

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.
With the move to unsafe effects, we no longer model `unsafe` as an
availability problem. Remove all of that supporting code.
@DougGregor
Copy link
Member Author

swiftlang/swift-syntax#2937

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

swiftlang/swift-syntax#2937

@swift-ci please build toolchain

@DougGregor
Copy link
Member Author

swiftlang/swift-syntax#2937

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

swiftlang/swift-syntax#2937

@swift-ci please build toolchain

@DougGregor
Copy link
Member Author

swiftlang/swift-syntax#2937

@swift-ci please build toolchain Linux

@DougGregor DougGregor merged commit ede7bfe into swiftlang:main Jan 11, 2025
6 checks passed
@DougGregor DougGregor deleted the unsafe-effect branch January 11, 2025 07:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant