Repository navigation
if/else inside Group { … } builder triggers Swift type-checker crash #158
Description
Activity
Workaround caveat (from v0.0.5 probes)
The workaround documented in the issue body ("hoist the conditional into a helper function") only works if the helper uses plain Swift
if/elseto return one of twoCodeBlocks. Wrapping the helper's body inGroup { if … }still trips the type-checker crash inside the helper:// ❌ Still crashes — the inner Group hits the same overload-resolution issue. public func optionalDebugField(_ include: Bool) -> any CodeBlock { Group { if include { Variable(.let, name: "debug", type: "Bool") } } } // ✅ Works — plain Swift control flow, no result builder. public func optionalDebugField(_ include: Bool) -> any CodeBlock { if include { return Variable(.let, name: "debug", type: "Bool") } else { return Group {} // empty Group as the "no-op" CodeBlock; there's no // public EmptyCodeBlock type to return otherwise. } }
The second form renders cleanly through
skit run. Also worth noting: there's no public empty-CodeBlock type, so the false branch has to return an emptyGroup { }. A publicEmptyCodeBlock(or makingCodeBlock?valid in builders) would be a small ergonomic win.
Repro
Fails to compile with:
Confirmed against
Apple Swift version 6.3.2 (swiftlang-6.3.2.1.108)onarm64-apple-macosx26.0against SyntaxKit ate5b1b73(research/swift-manifest-codegen).What should happen
CodeBlockBuilderResultdeclaresbuildEither(first:),buildEither(second:),buildOptional, andbuildArray(Sources/SyntaxKit/CodeBlocks/CodeBlockBuilderResult.swift:46-71), so the API surface saysif/elseinside the builder is supported. The Swift type-checker should either accept the expression or emit a real diagnostic.Probable cause
The type-checker is bailing out on overload resolution.
CodeBlockBuilderResulthas twobuildBlockvariants —(any CodeBlock...) -> [any CodeBlock]and([any CodeBlock]...) -> [any CodeBlock]— combined withbuildEither/buildOptional/buildArrayoverany CodeBlockexistentials. The combination is likely exhausting the type-checker's effort budget and triggering the "failed to produce diagnostic" fallback rather than a real error.Impact
Users can't write conditional codegen at the top level of a builder closure, even though the API documents it as supported. Affects anyone trying to emit conditional structures (platform gates, debug-only fields, optional members from runtime config, etc.). No unit tests under
Tests/SyntaxKitTests/Unit/exercise anifinsideGroup { … }, which is why this hasn't been caught.Workaround
Hoist the conditional into a normal function that returns
any CodeBlock, then call the function from inside the builder — the type-checker never sees theifat the builder level.References