Skip to content

Add a kind to Issue.record to record various kinds a of issues #1120

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
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

suzannaratcliff
Copy link
Contributor

Add a kind to Issue.record to record various kinds a of issues

Motivation:

I would like to be able to specify what kind of issue I am recording when I record an issue.

Modifications:

Add an optional parameter to Issue.record that takes in an issue Kind.

Checklist:

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

@@ -86,10 +87,11 @@ extension Issue {
@discardableResult public static func record(
_ comment: Comment? = nil,
severity: Severity,
sourceLocation: SourceLocation = #_sourceLocation
sourceLocation: SourceLocation = #_sourceLocation,
kind: Kind = .unconditional
Copy link
Contributor

Choose a reason for hiding this comment

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

I recall this is the overload of record() you added previously, and its primary difference from the existing, public API is that it includes a severity: parameter. This one is currently @_spi(Experimental), and I think that SPI level makes sense given your active pitch which seeks to elevate this overload to non-SPI and replace the older one entirely. If that proposal advances and is accepted, I think we will want to expose this record() method as it's currently written and proposed, without including a kind: parameter in its signature.

Given those plans, I think it may make more sense in this PR to expose an entirely new overload of the record() function which includes the kind: parameter, and leave the existing overload alone. And that overload can have two SPI groups—@_spi(Experimental) and @_spi(ForToolsIntegrationOnly)—to reflect that it's intended for use by integrated tools.

I would also suggest placing kind: as the first parameter in that new overload, and giving its comment parameter a label (instead of _ comment: Comment?).

Copy link
Contributor

Choose a reason for hiding this comment

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

It should never be possible to create an issue with an arbitrary kind field via API or non-experimental SPI, so we need to nix that argument for any public interfaces.

@stmontgomery stmontgomery added enhancement New feature or request tools integration 🛠️ Integration of swift-testing into tools/IDEs issue-handling Related to Issue handling within the testing library labels May 20, 2025
@stmontgomery stmontgomery added this to the Swift 6.x milestone May 20, 2025
@stmontgomery
Copy link
Contributor

@swift-ci please test

@_spi(Experimental)
@_spi(ForToolsIntegrationOnly)
@discardableResult public static func record(
kind: Kind = .unconditional,
Copy link
Contributor

Choose a reason for hiding this comment

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

Ok now that this is a distinct overload, I think you'll need to make kind: not have a default value at all, because all parameters have a default value now and Issue.record() (zero args) may be ambiguous with the public API

Suggested change
kind: Kind = .unconditional,
kind: Kind,

/// - severity: The severity of the issue.
/// - sourceLocation: The source location to which the issue should be
/// attributed.
/// - kind: The kind of the issue.
Copy link
Contributor

Choose a reason for hiding this comment

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

kind can move up to the top, now

Copy link
Contributor

Choose a reason for hiding this comment

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

It should be deleted.

@@ -92,6 +92,34 @@ extension Issue {
let issue = Issue(kind: .unconditional, severity: severity, comments: Array(comment), sourceContext: sourceContext)
return issue.record()
}

/// Record an issue when a running test fails unexpectedly.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
/// Record an issue when a running test fails unexpectedly.
/// Record an issue with a specific kind.

Copy link
Contributor

@grynspan grynspan left a comment

Choose a reason for hiding this comment

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

It is intentional that we don't provide API or SPI to create an Issue with an arbitrary kind field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request issue-handling Related to Issue handling within the testing library tools integration 🛠️ Integration of swift-testing into tools/IDEs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants