Skip to content

Conversation

@grynspan
Copy link
Contributor

@grynspan grynspan commented Jul 17, 2024

This PR lowers some API symbols to SPI, mostly as experimental tools-only. These symbols are, we believe, important but deserve more thought and design before we promote them to API.

As well, this PR merges the comment and comments properties of ConditionTrait as redundant.

Resolves rdar://131937376.

Checklist:

  • Code and documentation should follow the style of the Style Guide.
  • If public symbols are renamed or modified, DocC references should be updated.

This PR lowers some API symbols to SPI, mostly as experimental tools-only. These
symbols are, we believe, important but deserve more thought and design before we
promote them to API.

As well, this PR merges the `comment` and `comments` properties of
`ConditionTrait` as redundant.

Resolves rdar://131937376.
@grynspan grynspan added tools integration 🛠️ Integration of swift-testing into tools/IDEs public-api Affects public API labels Jul 17, 2024
@grynspan grynspan self-assigned this Jul 17, 2024
@grynspan
Copy link
Contributor Author

@swift-ci please test

@grynspan
Copy link
Contributor Author

@swift-ci please test

…, which is nonsensical--expose the ID type opaquely instead
@grynspan
Copy link
Contributor Author

@swift-ci please test

@grynspan grynspan merged commit 2b1d626 into main Jul 17, 2024
@grynspan grynspan deleted the jgrynspan/131937376-lower-some-symbols branch July 17, 2024 20:43
// See https://swift.org/CONTRIBUTORS.txt for Swift project authors
//

@_spi(ForToolsIntegrationOnly)
Copy link
Contributor

@stmontgomery stmontgomery Jul 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried about this change -- making the Identifiable conformance public and also making its ID type public. Test.Case.ID is not yet fully designed and, in some scenarios will not actually uniquely identify a test case. When its argumentIDs property is nil (which is the case if any argument is non-Codable or equivalent), it will be considered equal to all other instances representing non-Codable arguments. This could be confusing to users or lead to bugs.

This is a known limitation of this ID type currently which we need to come back and fix, but the current tool adopters already use it properly with that consideration in mind. But if we make this change it will publish this ID type as API and I don't think it is mature or robust enough yet.

The existing solution was to wrap this entire extension in @_spi. Can you elaborate on why that is problematic? A runtime as? Identifiable cast may succeed, but since the concrete ID type is not public, I did not think this would be a problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Protocol conformances are always as visible as the type/protocol in question. See here: https://developer.apple.com/documentation/testing/test/case#relationships

If we don't want the conformance to be public, we'll have to remove it outright.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Behold:

func idForTestCase(_ testCase: Test.Case) -> some Hashable {
  func thunk(_ x: some Identifiable) -> some Hashable {
    x.id
  }
  return thunk(testCase)
}

Contrived, but the point is the IDs are publicly accessible already.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, due to opaque types, this is valid even when everything's SPI and you haven't imported it:

let x = Test.Case.current!.id
let y = Test.Case.current!.id
#expect(x == y)

So yeah, we need to pick a side of the fence to be on here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, let's just remove the Identifiable conformance

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@briancroom Thoughts?

grynspan added a commit that referenced this pull request Jul 19, 2024
With further consideration after #548, we've decided to remove conformance to
`Identifiable` from `Test.Case` rather than promoting it to API. The identity of
a test case is fuzzy because it depends on the arguments to a test, not all of
which may be uniquely identifiable. We need more time to consider the design of
this part of the interface before making it a permanent part of our API.
grynspan added a commit that referenced this pull request Jul 19, 2024
With further consideration after #548, we've decided to remove conformance to
`Identifiable` from `Test.Case` rather than promoting it to API. The identity of
a test case is fuzzy because it depends on the arguments to a test, not all of
which may be uniquely identifiable. We need more time to consider the design of
this part of the interface before making it a permanent part of our API.
grynspan added a commit that referenced this pull request Jul 19, 2024
With further consideration after #548, we've decided to remove
conformance to `Identifiable` from `Test.Case` rather than promoting it
to API. The identity of a test case is fuzzy because it depends on the
arguments to a test, not all of which may be uniquely identifiable. We
need more time to consider the design of this part of the interface
before making it a permanent part of our API.

### 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

Labels

public-api Affects public API tools integration 🛠️ Integration of swift-testing into tools/IDEs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants