Update Comment to use CustomTestStringConvertible during string interpolation.

[grynspan]

This PR ensures that Comment, when constructed from a string literal with interpolations, stringifies interpolated values using String.init(descriptionForTest:) rather than the default behaviour (i.e. String.init(description:).)

For example:

enum E: CustomTestStringConvertible {
  case a
  case b
  case c

  var testDescription: String {
    switch self {
    case .a:
      "Once I was the King of Spain"
    case .b:
      "Now I eat humble pie"
    case .c:
      "Now I vacuum the turf at SkyDome™"
    }
  }
}

 #expect(1 == 2, "\(E.a) / \(E.b) / \(E.a) / \(E.c)")

Before:

🛑 Expectation failed: 1 == 2 - .a / .b / .a / .c

After:

🛑 Expectation failed: 1 == 2 - Once I was the King of Spain / Now I eat
humble pie / Once I was the King of Spain / Now I vacuum the turf at SkyDome™

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

[stmontgomery]

Not sure about this, might be too magical and surprising compared to how string literal interpolation usually works. Is there a strong reason to include it?

[grynspan]

My expectation here (heh) is that if you pass an optional value in a testing context, you want to see its value. Also the warning's fix-it is emitted by the compiler and tells you to use String(describing:), not String(describingForTest:), which is wrong.

[stmontgomery]

I wouldn't say it's wrong for the compiler to suggest that; users are welcome to call String(describing:) themselves. I think String(describingForTest:) is primarily for the testing library to call on values users provide, and (to a lesser extent) for use by test authors when writing helpers/utilities.

I think this violates the principle of least surprise. Regardless of what we think of the compiler's fix-it, users are generally accustomed to needing to handle optionals in string interpolations, and I don't know of a reason to deviate from that precedent here. It makes it seem as if the rules are more lax just because it's a test.

[grynspan]

The compiler emits that diagnostic because the default string representation of an optional value may either be "Optional(x)" (where x is the wrapped value's description) or "nil", and neither of those values is likely expected by a developer who wants to just print x. In our case, that doesn't hold because optional values already have special handling in the library.

I would expect the following code to "just work" rather than emitting any diagnostics, for instance:

let x: Int? = f()
#expect(x == 10, "\(x) should be 10!")

[stmontgomery]

Great enhancement overall. I'm still not convinced about the merit of the overload which suppresses warnings for optionals, and worry it could be surprising or confusing. But it's admittedly a minor concern and I don't want to stand in the way of the broader PR.

[grynspan]

@swift-ci test