-
Notifications
You must be signed in to change notification settings - Fork 466
Add support for Swift Testing in SwiftSyntaxMacrosTestsSupport #3192
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
Open
0xTim
wants to merge
6
commits into
swiftlang:main
Choose a base branch
from
0xTim:support-swift-testing
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
2ddc19b
Record issues if we're in a Swift testing environment
0xTim ba15ee0
Add support in other method
0xTim dff2179
Add tests
0xTim d7fd8ff
Private imports
0xTim 8f55686
Fix some of the CI issues
0xTim be537f1
Fix formatting
0xTim File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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 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
61 changes: 61 additions & 0 deletions
61
Tests/SwiftSyntaxMacroExpansionTest/SwiftTestingTests.swift
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,61 @@ | ||
| //===----------------------------------------------------------------------===// | ||
| // | ||
| // This source file is part of the Swift.org open source project | ||
| // | ||
| // Copyright (c) 2014 - 2023 Apple Inc. and the Swift project authors | ||
| // Licensed under Apache License v2.0 with Runtime Library Exception | ||
| // | ||
| // See https://swift.org/LICENSE.txt for license information | ||
| // See https://swift.org/CONTRIBUTORS.txt for the list of Swift project authors | ||
| // | ||
| //===----------------------------------------------------------------------===// | ||
|
|
||
| #if canImport(Testing) | ||
| import Testing | ||
| import SwiftSyntaxMacrosTestSupport | ||
|
|
||
| @Suite("Swift Testing Macro Expansion Tests") | ||
| struct SwiftTestingMacroExpansionTests { | ||
| @Test("Test Happy Path") | ||
| func testHappyPathWorks() { | ||
| assertMacroExpansion( | ||
| """ | ||
| @constantOne | ||
| var x: Int /*1*/ // hello | ||
| """, | ||
| expandedSource: """ | ||
| var x: Int { /*1*/ // hello | ||
| get { | ||
| return 1 | ||
| } | ||
| } | ||
| """, | ||
| macros: ["constantOne": ConstantOneGetter.self], | ||
| indentationWidth: .spaces(2) | ||
| ) | ||
| } | ||
|
|
||
| @Test("Test Failure") | ||
| func failureReportedCorrectly() { | ||
| withKnownIssue { | ||
| assertMacroExpansion( | ||
| """ | ||
| @constantOne | ||
| var x: Int /*1*/ // hello | ||
| """, | ||
| expandedSource: """ | ||
| var x: Int { /*1*/ // hello | ||
| get { | ||
| return 1 | ||
| } | ||
| } | ||
| """, | ||
| macros: ["constantOne": ConstantOneGetter.self], | ||
| indentationWidth: .spaces(4) | ||
| ) | ||
| } matching: { issue in | ||
| issue.description.contains("Macro expansion did not produce the expected expanded source") | ||
| } | ||
| } | ||
| } | ||
| #endif |
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not the correct test to determine which library is in use because code can run in a detached task. See swiftlang/swift-testing#475
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the correct way? Should we split it out into a
expectfunction instead?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no correct way at this time, which is why that issue is still open. Jerry's work should allow us to just call
#expect()here and have it work under all configurations.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pitch looks like it will solve the issue, but still require work in the library to migrate over to Swift Testing APIs. What I propose is that we land this now, as it solves a problem that exists for users today (and potentially provide a release in the next monthly Linux release/Swift patch release) and then fix forward when the proposal lands. Given it's still in the pitch phase it likely won't be landed until 6.4 and waiting 10 months for a solution seems like a bad idea.
Regarding the
Test.currentissue - from my understanding this works in all instances apart from those running in a detached task. For this specific case, I can't see a scenario when a user would be using theassertMacroExpansionfrom a detached task so we can fix this for the majority of the users and those attempting to use it from a detached task will see no change in behaviour.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stmontgomery Your take? You okay with this presumably being nonfunctional with the package build?
Let's at least document it as unsupported in the symbol's Markup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be morally okay with saying "the features in the swift-syntax repository are dependent on the built-in copy of Swift Testing even if you include a package dependency" however this will break builds on non-Apple platforms with flat linker namespaces due to duplicate symbols at link time.
Once @jerryjrchen's work on the interop feature lands, it will be possible to implement this in a way that depends on neither XCTest nor Swift Testing. It may be a better idea to just wait until that work is done and revisit the problem at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only if there is both
Testingfrom the toolchain and from the package right? Which I thought we agreed is only really valid in development environments.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All testing environments are development environments.
If swift-syntax explicitly links the copy of Swift Testing in the toolchain, that will break developers who want to test their macros and have a package dependency on Swift Testing.
In addition, if they are using the package copy of Swift Testing and you are using the toolchain's copy, your calls to e.g.
#expect()won't be routed to the infrastructure the developer's test target links against, so a failure will be invisible.Jerry's work should give us an escape hatch for this problem, so we should wait until it lands and then make the necessary changes here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern with waiting is that it could be a year until that's shipped, meanwhile users have no indications their tests are passing incorrectly, whereas we could fix it today for the majority of use cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the concern, but there are technical blockers here. We must not cause build failures for teams using Swift Testing as a package.