Allow combining SwiftParser and SwiftSyntaxBuilder to generate source code

[ahoppen]

This is a proof-of-concept how the parser can be used to generate SwiftSyntax trees for statically known boilerplate while using SwiftSyntaxBuilder for repetitive or dynamic constructs.

Once this is merged, I will try to migrate generate-swiftsyntaxbuilder to this scheme to make it easier to read.

Also ignore how messy BuildableNodes.swift looks by now. I will try to clean it up once generate-swiftsyntaxbuilder has been migrated to use the parser and is thus easier to work with.

Example

This allows us to generate

func plusOne(base: Int) -> Int {
  switch base {

  case 0:
    return 1
  case 1:
    return 2
  default:
    return -1
  }
}

by constructing the repetitive cases using SwiftSyntaxBuilder (which can play its strength here)

let cases = SwitchCaseList {
  for i in 0..<2 {
    SwitchCase("""
    case \(i):
      return \(i + 1)
    """)
  }
}

and all the static boilerplate by invoking the parser with string interpolation to add the cases.

let plusOne = FunctionDeclSyntax("""
func plusOne(base: Int) -> Int {
  switch base {
  \(cases)
  default:
    return -1
  }
}
""")

[ahoppen]

@swift-ci Please test

[ahoppen]

@swift-ci Please test

[fwcd]

Cool, this looks very interesting! I haven't dug too deep into this and SwiftParser in general, so I can't comment on the details, but some minor notes below.

[fwcd]

These switch statements can be written a bit more concisely using the builder-based initializers. I usually also keep the label/caseItems/pattern/expression boilerplate on a single line, but perhaps there is some other way too to avoid the pyramid of doom here.

Suggested change

	SwitchStmt(expression: "data", cases: SwitchCaseList([
	SwitchCase(
	label: SwitchCaseLabel(
	caseItems: CaseItem(
	pattern: ExpressionPattern(
	expression: FunctionCallExpr(MemberAccessExpr(name: "buildable")) {
	TupleExprElement(
	expression: UnresolvedPatternExpr(
	pattern: ValueBindingPattern(
	letOrVarKeyword: .let,
	valuePattern: IdentifierPattern("buildableData")
	)
	)
	)
	}
	)
	)
	),
	statements: CodeBlockItemList {
	CodeBlockItem(
	item: ReturnStmt(expression: SequenceExpr {
	MemberAccessExpr(base: "buildableData", name: "trailingComma")
	BinaryOperatorExpr("!=")
	NilLiteralExpr()
	})
	)
	}
	),
	SwitchCase(
	label: SwitchCaseLabel(
	caseItems: CaseItem(
	pattern: ExpressionPattern(
	expression: FunctionCallExpr(MemberAccessExpr(name: "constructed")) {
	TupleExprElement(
	expression: UnresolvedPatternExpr(
	pattern: ValueBindingPattern(
	letOrVarKeyword: .let,
	valuePattern: IdentifierPattern("node")
	)
	)
	)
	}
	)
	)
	),
	statements: CodeBlockItemList {
	CodeBlockItem(
	item: ReturnStmt(expression: SequenceExpr {
	MemberAccessExpr(base: "node", name: "trailingComma")
	BinaryOperatorExpr("!=")
	NilLiteralExpr()
	})
	)
	}
	)
	]))
	SwitchStmt(expression: "data") {
	SwitchCase(
	label: SwitchCaseLabel(
	caseItems: CaseItem(
	pattern: ExpressionPattern(
	expression: FunctionCallExpr(MemberAccessExpr(name: "buildable")) {
	TupleExprElement(
	expression: UnresolvedPatternExpr(
	pattern: ValueBindingPattern(
	letOrVarKeyword: .let,
	valuePattern: IdentifierPattern("buildableData")
	)
	)
	)
	}
	)
	)
	)
	) {
	ReturnStmt(expression: SequenceExpr {
	MemberAccessExpr(base: "buildableData", name: "trailingComma")
	BinaryOperatorExpr("!=")
	NilLiteralExpr()
	})
	}
	SwitchCase(
	label: SwitchCaseLabel(
	caseItems: CaseItem(
	pattern: ExpressionPattern(
	expression: FunctionCallExpr(MemberAccessExpr(name: "constructed")) {
	TupleExprElement(
	expression: UnresolvedPatternExpr(
	pattern: ValueBindingPattern(
	letOrVarKeyword: .let,
	valuePattern: IdentifierPattern("node")
	)
	)
	)
	}
	)
	)
	)
	) {
	ReturnStmt(expression: SequenceExpr {
	MemberAccessExpr(base: "node", name: "trailingComma")
	BinaryOperatorExpr("!=")
	NilLiteralExpr()
	})
	}
	}
	}

[ahoppen]

Thanks. That’s a little cleaner. I’ll probably migrate all of this to be parser-based in a follow-up PR.

[fwcd]

Similarly for these switch statements

[fwcd]

I'm not that familiar with SwiftParser yet, so apologies if I'm missing something. Why do we need an indentation rewriter within the parser? Don't Swift's multi-line string literals already handle indentation properly?

[ahoppen]

The problem is that if you have

let nested = """
first
second
"""

let wrapping = """
  \(nested)
"""

print(wrapping)

you get

  first
second

where second is not indented. Basically all I’m doing here is indenting all lines in the string interpolation to the current indentation level.

[ahoppen]

@swift-ci Please test