Preserve contextual type for literal `arguments:` expressions in `@Test` by ojun9 · Pull Request #1627 · swiftlang/swift-testing

ojun9 · 2026-03-15T09:03:20Z

Preserve contextual type for literal arguments: expressions in @Test

Motivation:

Parameterized tests using @Test(arguments:) may fail to compile when the collection is written as an array literal containing values that rely on contextual type inference.

For example:

@Test<[(String?, Int?)]>(arguments: [
  (nil, 2),
  ("c", nil),
  ("d", nil)
])
func f(s: String?, i: Int?) {}

During macro expansion, the arguments: expression is wrapped in a closure so the collection can be evaluated lazily:

arguments: { [...] }

When the array literal is evaluated inside this closure, the contextual type that would normally be provided by the test function parameters is no longer available. As a result, values such as nil cannot be inferred and the code fails to type-check.

The same code works if the array literal is explicitly cast:

@Test(arguments: [
  (nil, 1),
  ("a", nil)
] as [(String?, Int?)])
func f(s: String?, i: Int?) {}

In this case the generated code becomes:

arguments: { [...] as [(String?, Int?)] }

The explicit cast preserves the contextual type inside the closure and allows the literals to type-check.

Modifications:

When arguments: is supplied as a single array literal, the macro derives the expected array type from the test function parameter list and applies it as an explicit cast inside the generated closure.

For example, the generated expression becomes:

arguments: { [...] as [(String?, Int?)] }

This preserves the contextual type required for literal inference while keeping the existing lazy evaluation behavior.

Macro expansion only has access to source syntax and does not observe the inferred collection type directly. For this reason, the array type is derived from the test function parameter list. The change is intentionally limited to the case where arguments: is a single array literal so that other overloads remain unaffected.

Additional tests verify that contextual types are preserved for empty array literals and tuple literals containing optionals.

Checklist:

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

grynspan · 2026-03-15T13:03:38Z

Type checking of arguments to the @Test macro occurs before the expansion itself. Did you test this change to confirm it actually works? The added test only checks the macro expansion (without any type checking).

grynspan

Additional test coverage is needed too.

grynspan · 2026-03-15T13:50:08Z

+      return nil
+    }
+
+    if testFunctionArguments.count == 1, expression.is(ArrayExprSyntax.self) {


It should be safe to generalize this so that the argument count only needs to match the parameter count.

grynspan · 2026-03-15T13:50:31Z

+    }
+
+    let parameters = functionDecl.signature.parameterClause.parameters
+    guard !parameters.isEmpty else {


Suggested change

guard !parameters.isEmpty else {

if parameters.isEmpty {

grynspan · 2026-03-15T13:50:55Z

+  private func _contextualTypeForLiteralArgument(
+    for expression: ExprSyntax,
+    among testFunctionArguments: [Argument]
+  ) -> String? {


Suggested change

) -> String? {

) -> TypeSyntax? {

grynspan · 2026-03-15T13:54:43Z

+        // type itself, not tuple-shaped elements.
+        return "[\(parameter.baseTypeName)]"
+      }
+      let elementType = parameters.map(\.baseTypeName).joined(separator: ", ")


Can we construct an ArrayTypeSyntax here instead and leave the string interpolation to swift-syntax?

grynspan · 2026-03-15T13:55:06Z

+      if parameters.count == 1, let parameter = parameters.first {
+        // A single-parameter test expects collection elements of the parameter
+        // type itself, not tuple-shaped elements.
+        return "[\(parameter.baseTypeName)]"


Tokens from the original source need to be trimmed.

grynspan · 2026-03-15T13:56:36Z

      arguments += testFunctionArguments.map { argument in
        var copy = argument
-        copy.expression = .init(ClosureExprSyntax { argument.expression.trimmed })
+        let argumentExpr = argument.expression.trimmed


We can simplify this part of the diff by modifying argumentExpr before creating the closure wrapper.

ojun9 · 2026-03-17T05:01:12Z

Thanks for the question.

You're right that the existing test only verifies the macro expansion.
The change is not intended to make the following case compile:

@Test(arguments: [
  (nil, 1),
  ("a", nil)
])
func f(s: String?, i: Int?) {}

This case fails with Type of expression is ambiguous without a type annotation even without the macro, because the array literal lacks a contextual type.

The change addresses the situation where the collection type is already provided, for example via a generic parameter:

@Test<[(String?, Int?)]>(arguments: [
  (nil, 2),
  ("c", nil),
  ("d", nil)
])
func f(s: String?, i: Int?) {}

In this situation the collection element type is known, but wrapping the literal inside the generated closure removes the contextual type required for literal inference.

The added cast restores that contextual type and allows the code to compile.
I confirmed that this generic-parameter case compiles correctly with the change.

grynspan · 2026-03-25T12:25:40Z

I haven't forgotten about this PR, but I have been tied up with other work.

We should make sure to handle dictionary literals correctly as well, and can improve test efficiency by inferring them as instances of KeyValuePairs rather than Dictionary. Note that tuple desugaring on dictionary elements is always to exactly two test function arguments and does not occur if there are multiple argument collections in the @Test macro.

grynspan

We still need some fixture tests in the TestingTests target. See NonSendableTests for an example of how to write one (empty test that triggers this macro expansion code when we compile our own tests so that if the code isn't working, we fail to build). Those tests should go in the TestingTests target.

grynspan · 2026-03-25T12:29:59Z

    // trying to obtain the base type to reference it in an expression.
    let baseType = type.as(AttributedTypeSyntax.self)?.baseType ?? type
-    return baseType.trimmedDescription
+    return baseType.trimmed


Avoid trimming both here and in the call sites as it's somewhat expensive. I would leave it untrimmed here so that it can still be used for diagnostic attribution, but either choice is fine.

grynspan · 2026-03-25T12:31:56Z

+            )
+          )
+        }
+        let lazyExpression = expr.trimmed


Already trimmed by this point. (New nodes created programmatically are de facto trimmed if you don't explicitly specify trivia).

grynspan · 2026-04-14T19:11:58Z

  @Test(.hidden, arguments: [("value", 123)])
  func one2TupleParameter(x: (String, Int)) {}

+  @Test<[(String?, Int?)]>(.hidden, arguments: [


Suggested change

@Test<[(String?, Int?)]>(.hidden, arguments: [

@Test(.hidden, arguments: [

Generic parameters on @Test are not supported and will diagnose if used.

I removed the unsupported generic argument clause from @test.

The remaining type annotation is expressed as an explicit cast on the arguments: expression.
This preserves contextual type information (particularly for nil literals) and is consistent with the macro’s supported expansion semantics.

grynspan · 2026-04-14T19:12:08Z

  @Test(.hidden, arguments: ["value": 123])
  func oneDictionaryElementTupleParameter(x: (key: String, value: Int)) {}

+  @Test<KeyValuePairs<String, Int?>>(.hidden, arguments: [


Suggested change

@Test<KeyValuePairs<String, Int?>>(.hidden, arguments: [

@Test(.hidden, arguments: [

Generic parameters on @Test are not supported and will diagnose if used.

grynspan · 2026-04-14T19:12:36Z

Sorry for the delay! I was out sick.

Co-authored-by: Jonathan Grynspan <grynspan@me.com>

grynspan · 2026-04-20T14:24:18Z

Let me know when you're ready for another review.

ojun9 · 2026-04-20T14:30:29Z

@grynspan
No worries, hope you're feeling better!
Ready for another review!

grynspan · 2026-05-01T15:40:11Z

If you see the "merge" button, please make sure to squash. Otherwise ping me and I'll click the button.

…airs`. (#1699) This change ensures that test authors who explicitly pass collections of type `KeyValuePairs<K, V>` as test arguments will get the same sort of optimizations as they would if they passed a `Dictionary<K, V>` instead. This change complements, but is not dependent on, #1627. ### 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 · 2026-05-01T18:19:50Z

+        return TypeSyntax(
+          MemberTypeSyntax(
+            baseType: IdentifierTypeSyntax(name: .identifier("Swift")),
+            name: .identifier("KeyValuePairs"),


I'm surprised to see DictionaryExprSyntax being interpreted as KeyValuePairs. I see this comment which I'm guessing is what led to that:

We should make sure to handle dictionary literals correctly as well, and can improve test efficiency by inferring them as instances of KeyValuePairs rather than Dictionary.

That changes the semantics some, though: elements with equal keys will run the test multiple times, and the order we dispatch test cases in will be stable, whereas with a dictionary the order is nondeterministic due to hashing.

Is switching to KeyValuePairs necessary for this overall PR, or is it more of an opportunistic performance improvement? It feels like a potentially user-observable behavior change.

This was my suggestion, yes.

That changes the semantics some, though: elements with equal keys will run the test multiple times

Equal keys crash outright with a dictionary when it is initialized.

and the order we dispatch test cases in will be stable, whereas with a dictionary the order is nondeterministic due to hashing.

This change is more consistent with how we treat arrays, yes.

Is switching to KeyValuePairs necessary for this overall PR, or is it more of an opportunistic performance improvement? It feels like a potentially user-observable behavior change.

It isn't strictly necessary, but the only user-observable change is that the random order of elements is no longer random (which we never really intended it to be anyway).

stmontgomery · 2026-05-01T21:50:23Z

+    (nil, 123),
+    ("value1", nil),
+    ("value2", nil),
+  ] as [(String?, Int?)])


Why does this test, and the other new one below, include an explicit as cast on the passed-in collection? I thought this PR was intended to remove the need to specify that at the point where @Test is used?

I just pulled the branch locally, and when I try this example mentioned in the PR description without an as cast and without <...> generic type parameters on @Test, it's still emitting an error:

@Test(arguments: [ (nil, 2), // ❌ error: 'nil' cannot initialize specified type 'String' ("c", nil), ("d", nil) ]) func f(s: String?, i: Int?) {}

If the outcome of this PR is that a user still needs to either (a) use an explicit as cast or (b) include generic type parameters on @Test, then I'm not sure what the benefit is. Users can already do (a), and we recently began emitting a warning diagnostic for (b), and it's not meaningfully simpler than option (a) IMO anyway.

stmontgomery

I appreciate your effort on this @ojun9 — I really do want to see this problem resolved so that test authors don't need to provide type information for test arguments explicitly. In fact, I took a stab at it myself a while back in this PR.

I'm concerned though that as written, it doesn't really help much in practice towards that goal. Unless I'm missing something, it seems like it still requires specifying the type of the argument collection explicitly.

If that's not accurate, or if there are scenarios where this is helpful without explicit type info that I'm overlooking, could you please give an example of that?

ojun9 · 2026-05-26T14:13:56Z

@stmontgomery

Sorry for the very delayed reply.

Thanks, I see your point.

The case this PR helps with is one where the type is already provided somehow before expansion, for example:

@Test<[(String?, Int?)]>(arguments: [
(nil, 2),
("c", nil),
("d", nil),
])
func f(s: String?, i: Int?) {}

In this case, the original arguments: expression has enough context to type-check, but the generated closure loses that context unless the expansion adds as [(String?, Int?)].

That said, I agree this is still explicit type information at the use site. I don’t currently know of an example where this PR makes the literal work with neither an as cast nor a generic argument clause.

Preserve contextual type for literal arguments wrapped by @test macro

1912d84

ojun9 requested review from briancroom, grynspan, harlanhaskins, jerryjrchen and stmontgomery as code owners March 15, 2026 09:03

grynspan requested changes Mar 15, 2026

View reviewed changes

ojun9 and others added 4 commits March 17, 2026 14:05

review feedback

91213c6

review feedback

c27dc5c

review feedback

8d51562

Merge branch 'main' into fix/macro-literal-contextual-type

51456e9

ojun9 requested a review from grynspan March 17, 2026 13:10

grynspan assigned ojun9 Mar 19, 2026

grynspan added bug 🪲 Something isn't working macros 🔭 Related to Swift macros such as @Test or #expect labels Mar 19, 2026

grynspan added this to the Swift 6.4.0 (main) milestone Mar 19, 2026

omochi mentioned this pull request Mar 25, 2026

Specifying the type parameter for the @Test macro may not always enable type inference for arguments. #1639

Closed

grynspan reviewed Mar 25, 2026

View reviewed changes

Comment thread Sources/TestingMacros/Support/Additions/FunctionDeclSyntaxAdditions.swift

ojun9 added 4 commits March 26, 2026 22:19

Untrim baseType

5d3e5d0

Remove redundant trimming

a5b1498

Handle dictionary literal contextual types

9bdd79d

Add literal contextual typing fixtures

3d6b072

ojun9 requested a review from grynspan March 26, 2026 14:47

Merge branch 'main' into fix/macro-literal-contextual-type

90e47ed

grynspan reviewed Apr 14, 2026

View reviewed changes

Comment thread Sources/TestingMacros/Support/Additions/FunctionDeclSyntaxAdditions.swift Outdated

grynspan reviewed Apr 14, 2026

View reviewed changes

Comment thread Sources/TestingMacros/Support/AttributeDiscovery.swift Outdated

grynspan reviewed Apr 14, 2026

View reviewed changes

Comment thread Sources/TestingMacros/Support/AttributeDiscovery.swift

grynspan reviewed Apr 14, 2026

View reviewed changes

ojun9 and others added 6 commits April 20, 2026 22:44

Merge branch 'main' into fix/macro-literal-contextual-type

78e75ae

Update Sources/TestingMacros/Support/AttributeDiscovery.swift

5316889

Co-authored-by: Jonathan Grynspan <grynspan@me.com>

Update Tests/TestingTests/Test.Case.ArgumentTests.swift

542a027

Co-authored-by: Jonathan Grynspan <grynspan@me.com>

Update Tests/TestingTests/Test.Case.ArgumentTests.swift

ced014e

Co-authored-by: Jonathan Grynspan <grynspan@me.com>

cast contextual @test arguments

b64e134

qualify KeyValuePairs with Swift

04fa487

inline parameter base type return

988f08f

ojun9 requested a review from grynspan April 20, 2026 14:30

grynspan approved these changes May 1, 2026

View reviewed changes

grynspan mentioned this pull request May 1, 2026

Apply parameterized test optimizations for Dictionary to KeyValuePairs. #1699

Merged

2 tasks

stmontgomery reviewed May 1, 2026

View reviewed changes

grynspan requested a review from stmontgomery May 1, 2026 19:43

Merge branch 'main' into fix/macro-literal-contextual-type

7acf321

stmontgomery reviewed May 1, 2026

View reviewed changes

stmontgomery requested changes May 1, 2026

View reviewed changes

Merge branch 'main' into fix/macro-literal-contextual-type

4b870a3

grynspan modified the milestones: Swift 6.4.0, Swift 6.5.0 (main) Jun 18, 2026

	@Test<[(String?, Int?)]>(.hidden, arguments: [
	@Test(.hidden, arguments: [

	@Test<KeyValuePairs<String, Int?>>(.hidden, arguments: [
	@Test(.hidden, arguments: [

Uh oh!

Conversation

ojun9 commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation:

Modifications:

Checklist:

Uh oh!

grynspan commented Mar 15, 2026

Uh oh!

grynspan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ojun9 commented Mar 17, 2026

Uh oh!

grynspan commented Mar 25, 2026

Uh oh!

grynspan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

grynspan commented Apr 14, 2026

Uh oh!

grynspan commented Apr 20, 2026

Uh oh!

ojun9 commented Apr 20, 2026

Uh oh!

grynspan commented May 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stmontgomery left a comment

Choose a reason for hiding this comment

Uh oh!

ojun9 commented May 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ojun9 commented Mar 15, 2026 •

edited

Loading