[Experimental] Capturing values in exit tests

[grynspan]

This PR implements an experimental form of state capture in exit tests. If you specify a capture list on the test's body closure and explicitly write the type of each captured value, and each value conforms to Sendable, Codable, and (implicitly) Copyable, we'll encode them and send them "over the wire" to the child process:

let a = Int.random(in: 100 ..< 200)
await #expect(exitsWith: .failure) { [a = a as Int] in
  assert(a > 500)
}

This PR is incomplete. Among other details:

• Need to properly transmit the data, not stuff it in an environment variable
• Need to implement diagnostics correctly
• Need to figure out if ExitTest.CapturedValue and __Expression.Value have any synergy. (They do, but it's beyond the scope of this initial/experimental PR.)

We are ultimately constrained by the language here as we don't have real type information for the captured values, nor can we infer captures by inspecting the syntax of the exit test body (hence the need for an explicit capture list with types.) If we had something like decltype() we could apply during macro expansion, you wouldn't need to write x = x as T and could just write x. The macro would use decltype() to produce a thunk function of the form:

@Sendable func __compiler_generated_name__(aʹ: decltype(a), bʹ: decltype(b), cʹ: decltype(c)) async throws {
  let (a, b, c) = (aʹ, bʹ, cʹ)
  try await { /* ... */ }()
}

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]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[stmontgomery]

I'd find it nice if the two env vars used a similar naming convention as each other

[grynspan]

I'm not sure what you mean.

[stmontgomery]

Right, sorry for not elaborating…

My understanding of these two env vars is that they essentially contain a file handle to a pipe, and there's now two such pipes: one allowing communication from the parent to exit test child, and one allowing communication from the exit test child to the parent.

My suggestion was to choose names for these two env vars that more closely resemble each other, reflecting that they are "opposites", and convey the direction of communication (since they are each one-way). For example, you might choose:

• SWT_EXPERIMENTAL_PARENT_TO_EXIT_TEST_FILE_HANDLE, and
• SWT_EXPERIMENTAL_EXIT_TEST_TO_PARENT_FILE_HANDLE

You can tweak the wording of course, but I like that this example has symmetry between the names, you can tell at a glance which one is which direction, and they are more future-proof in the sense that each pipe could evolve to include more kinds of data.

[grynspan]

For the moment, their names represent what they are and what they do. In the future, if either/both become host to more functionality, we can rename them. There's no ABI stability concern here as both endpoints are the same version of Swift Testing.

[stmontgomery]

Understood that we're free to evolve them at any time and that's great. Still, I find them more self-describing if they conveyed their direction in the names. For example I don't know whether the "back channel" is going from parent to exit test or vice-versa without looking it up. Both pipes could be considered "back channels".

Can we incorporate this feedback if/when we elevate the feature to public, since that will involve removing "experimental" from the names?

[grynspan]

Let's save this discussion for a separate PR.

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[stmontgomery]

I think it would be helpful to rename the env vars as I suggested in a comment still, mainly to make their roles more self-describing. On the whole, this looks great though!

[grynspan]

@swift-ci test