Add unsafe keyword handling to macro expansions.
#1069
Merged
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
This PR changes the `@Test` and `#expect()` macros so they handle `unsafe` expressions the same way `try` and `await` expressions are handled. The propagation rules for `unsafe` aren't the same as for `try` and `await` (i.e. it doesn't colour the calling function), but the general way we handle the keyword is the same. I haven't attempted to avoid inserting `unsafe` if a function is not marked `@unsafe` as it complicates the necessary logic but has no effects at runtime.
grynspan
added
enhancement
grynspan
requested review from
stmontgomery,
briancroom,
SeanROlszewski and
suzannaratcliff
as code owners
|
@swift-ci test |
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
suzannaratcliff
approved these changes
Apr 14, 2025
2 tasks
stmontgomery
added a commit
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.
stmontgomery
added a commit
that referenced
this pull request
Apr 24, 2025
…nized `unsafe` keyword (#1093) This fixes another bit of fallout from #1069 when building this project's test targets with a 6.1 (or any pre-6.2) toolchain. The `unsafe` keyword was introduced in 6.2 as part of [SE-0458: Opt-in Strict Memory Safety Checking](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0458-strict-memory-safety.md). Older toolchains are not aware of it, so the fix is to avoid emitting expressions involving that keyword when the macro plugin has been built using an older toolchain. ### 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.
stmontgomery
added a commit
that referenced
this pull request
Apr 24, 2025
…wait in recorded issues (#1092) This fixes an issue where code comments placed before an expectation like `#expect()` which has effect introducer keywords like `try` or `await` are ignored, and ensures they are included in the recorded issue if the expectation fails. Consider this example of two failing expectations: ```swift // Uh oh! #expect(try x() == 2) // Uh oh! try #expect(x() == 2) ``` Prior to this PR, if `x()` returned a value other than `2`, there would be two issues recorded, but the second one would not have the comment `“Uh oh!”` because from the macro’s perspective, that code comment was on the `try` keyword and it could only see trivia associated with `#expect()`. Now, with the recent swift-syntax fix from swiftlang/swift-syntax#3037, the `try` keyword and its associated trivia can be included and this bug can be fixed. We recently adopted a new-enough swift-syntax in #1069, so the only fix needed is to adopt `lexicalContext` for this new purpose in our macro. ### 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.
This PR changes the
@Testand#expect()macros so they handleunsafeexpressions the same waytryandawaitexpressions are handled. The propagation rules forunsafearen't the same as fortryandawait(i.e. it doesn't colour the calling function), but the general way we handle the keyword is the same.I haven't attempted to avoid inserting
unsafeif a function is not marked@unsafeas it complicates the necessary logic but has no effects at runtime.Checklist: