Result builder syntax will lead to SourceKitService/swift-frontend infinite loop

[andrebraga]

This one will be a bit more involved, I think.

I'm trying to use this trivial result builder for convenience when outputting dynamic HTML.

@resultBuilder
struct StringBuilder {

  static func buildBlock(_ components: String...) -> String {
    components.joined()
  }

  static func buildBlock(_ components: CustomStringConvertible...) -> String {
    components.map(\.description).joined()
  }

  static func buildExpression(_ expression: String) -> String {
    expression
  }

  static func buildExpression(_ expression: CustomStringConvertible) -> String {
    expression.description
  }

  static func buildOptional(_ components: String?) -> String {
    components ?? ""
  }

  static func buildOptional(_ components: CustomStringConvertible?) -> String {
    components?.description ?? ""
  }

  static func buildEither(first components: String) -> String {
    components
  }

  static func buildEither(first components: CustomStringConvertible) -> String {
    components.description
  }

  static func buildEither(second components: String) -> String {
    components
  }

  static func buildEither(second components: CustomStringConvertible) -> String {
    components.description
  }

  static func buildArray(_ components: [String]) -> String {
    components.joined()
  }

  static func buildArray(_ components: [CustomStringConvertible]) -> String {
    components.map(\.description).joined()
  }
}

func str(@StringBuilder _ body: () -> String) -> String {
  body()
}

This will expand correctly:

let e: String = #html(div(str({ "d"; "e" })))

"<div>\(str({ "d"; "e" }))</div>" (Okay)

This will cause SourceKitService and swift-frontend to infinite-loop:

let e: String = #html(div(str({
  "d"
  "e"
})))

[RandomHashTags]

Can confirm problem. Working on a fix ASAP!

[RandomHashTags]

After much debugging, I have identified the cause. A fix will be very tedious and time consuming but I have began writing it.

[andrebraga]

I suspected as much from the very first sentence in my report... 😅

This does however open the doors to a very nice syntax for dynamic behaviour, if you're willing to accept one such PR. The current ergonomics of lifting conditionals and loop constructs to collected strings isn't that great. I suspect some performance hit will happen but many might prefer that... (and it's effectively impossible to plug that in via an extension because so much is pregenerated with the macros!)

[RandomHashTags]

PRs are very welcome! The same logic that allows interpolation to be written natively (without escaping it explicitly) needs to be expanded to include every Swift declaration, statement and expression. I have moved the logic into its own file for easier development.

[andrebraga]

Not necessarily every one of those! Only those supported by result builders...

[RandomHashTags]

I'm moving away from to_single_line function calling to a singleLineDescription : String public computed property extension for the syntax that need it. I believe this solution to be better, and everyone else can use it.

[RandomHashTags]

Fixed in latest commit. We can use String(describing:) here instead of interpolation. Thanks for reporting! <3