Update FCS

[nojaf]

Bump the vendored compiler sources from ab1f6cea to d05075e098278aedcea3379159504d664628a495, walking one upstream commit at a time rather than jumping, so a broken build is attributable to a single change.

Nineteen upstream commits touching src/Compiler/SyntaxTree are crossed. Most were clean bumps. Four needed real work.

[<return: Struct>] was being silently deleted

dotnet/fsharp#19738 made mkSynBinding move a [<return: ...>] attribute written in front of a binding out of SynBinding.attributes and into the arity information. Fantomas only reads the binding's attribute list, so those attributes were parsed and then never printed.

Partial active patterns marked [<return: Struct>] are the common case, and the Fantomas code base itself has 34 of them, so self-formatting would have removed every one. The existing tests only covered the return type annotation form, let f x : [<return: Attribute>] int = x, so the entire suite stayed green while source was being dropped. restoreRotatedReturnAttributes puts them back in the list they were written in, leaving annotation attributes alone since the return type node already prints those.

I raised the layering question upstream on dotnet/fsharp#19738: the rotation used to live in the type checker and patched a local copy, so the parse tree stayed faithful to the source. Moving it into the parser makes the untyped tree report no attributes for source that visibly has one, and it is lossy, [<return: A; return: B>] and [<return: A>][<return: B>] now produce identical trees.

Record spreads

dotnet/fsharp#18927, RFC FS-1151. New syntax in three tree positions, so Oak and CodePrinter needed real support:

{ ...source; Field = value }                  // record expression
{| ...source; Field = value |}                // anonymous record expression
type Target = { ...Source; Field: int }       // record type definition, also in signature files

Oak mirrors the upstream shape with two unions, ExprRecordFieldOrSpread and TypeDefnRecordFieldOrSpread, carrying ExprSpreadNode and TypeSpreadNode. Simplified where we can: nominal and anonymous record items keep sharing RecordFieldNode, which upstream splits in two, and the block separator is dropped since the printer decides separators itself. ExprRecordBaseNode.HasFields became HasItems, because a record holding only a spread has no fields but is not empty.

52 tests in a new RecordSpreadTests.fs cover the three positions in implementation and signature files, spreads before, between and after fields, multiple spreads, literals and applications and property gets as sources, struct anonymous records, Stroustrup, and comments attached to a spread.

Interpolated string alignment

dotnet/fsharp#19971 replaced FillExpr's qualifiers: Ident option with a SynInterpolationFormatting that models alignment and printf specifiers separately. {x,10} used to arrive as a tuple inside the fill expression, which is why Fantomas prints {x, 10}.

Absorbed entirely in ASTTransformer so the printer and the formatted output do not move: the alignment is folded back into the expression as the tuple the parser used to hand us. A printf specifier no longer appears in the preceding string part's text, so the fallback used when there is no source text re-appends it, otherwise %d{x} prints as {x} when formatting from an AST.

Alignment had no test coverage at all, which is what would have made this silent. There are four now, including one through the AST path.

$"{value,-10}" previously failed to parse and now formats.

The SR generator had to be vendored

dotnet/fsharp#20097 made diagnostic messages carry classified text, so every SR accessor generated from FSComp.txt returns RichText instead of string. The task that generates them, FSharpEmbedResourceText, ships in the .NET SDK and is older than the sources we vendor, so it cannot emit the classified accessors and the compiler no longer builds against it. Upstream avoids this by bootstrapping its own FSharp.Build.

We vendor that one task file instead and compile it in a new Fantomas.FCS.BuildTasks project. FSComp.txt moves out of EmbeddedText into an item of our own, which keeps the SDK's generator away from it, and a target mirroring the SDK's GenerateFSharpTextResources runs the vendored task over it. The namespace rewrite that already turns FSharp.Compiler into Fantomas.FCS on download also rewrites the namespace the task emits, so the generated SR opens Fantomas.FCS.Text without any extra machinery.

This is build tooling only. The published packages are unchanged.

Also

Each step was probed by hand with scripts/format.fsx, not just run against the suite, because the failure mode of a parser shape change is silently dropped source that no existing assertion notices. Two commits made the parser accept a layout it previously rejected, and Fantomas deliberately does not adopt either, since the vendored compiler runs ahead of the compiler in a published SDK and output only the newer one accepts would not compile for users.

.claude/commands/update-fcs.md documents the walk itself, including the traps found along the way.