Known limitations

Curb emits multi-line trivia — doc comments, verbatim string literals — as a raw source span, so their internal newlines survive unchanged while the breaks Curb emits itself use the configured line ending. The result is a file with mixed line endings.

This means dotnet format disagrees with Curb's output on any file containing doc comments whose source line endings differ from the configured end_of_line. It is the most common source of fixed-point failures in the twelve-repository comparison.

With both csharp_style_expression_bodied_properties = true and csharp_style_expression_bodied_accessors = true, the two conversions can produce different output on consecutive passes:

public int Count { get { throw new NotImplementedException(); } }
public int Count { get => throw new NotImplementedException(); }
public int Count => throw new NotImplementedException();
		

1. source
2. run 1
3. run 2 — different

The accessor-level conversion fires on run 1. The property-level conversion only recognises an accessor list that already has an arrow getter, so it fires on run 2. Two rules that should compose in one pass currently do not.

In certain initializer patterns, Curb's output indentation can change between consecutive passes. An initializer anchors to the indentation of the line it starts on; when Curb's own output moves that line, the next run anchors somewhere else. The same applies to comment alignment in some cases. It is the anchor mechanism being unstable under its own output on real code.