--- title: Conformance divergences description: Every case where Curb's output is not a fixed point of dotnet format or jb cleanupcode at all, and why no shape it could choose would be one. url: https://docs-v3-preview.elastic.dev/design-principles/conformance-divergences --- # Conformance divergences This page lists every known case where Curb's output `Z` is **not a fixed point** of a reference tool at all — `T(Z) != Z` — because the tool cannot recognise what Curb did, so no shape Curb could have chosen instead would fix it. See [conformance](/design-principles/conformance#when-tz-z-cannot-hold-at-all) for what that means and how it differs from the ordinary, unlisted case of a fixed point in a different shape than the tool's own (`X != Z` with `T(Z) == Z` still holding — expected, common, and reported only in aggregate by `./build.sh verifyexpectations`, not itemised here). Each row below is a deliberate, investigated choice, not an oversight — an undocumented `T(Z) != Z` fails CI. The table is sourced from `build/conformance-divergences.json`, the registry `./build.sh verifyexpectations` checks a discovered non-fixed-point against. Until `./build.sh options` generates this page from that file (tracked separately), keep the two in sync by hand when either changes. | Option key | Tool | Fixed point? | Why no shape survives | Case | |------------------------------------------------------------------------------------|----------------------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------| | `csharp_empty_block_style` | `dotnet format whitespace` | No | A ReSharper-only key `dotnet format` does not recognise at all — inert on its own. The divergence only shows up combined with `csharp_preserve_single_line_blocks = false`, an IDE0055 key `dotnet format` understands as "expand every single-line block," including the empty one Curb just recollapsed. The two are in permanent, direct conflict whenever both are set this way — no shape survives both at once. | `EmptyBlockStyleTests.Together_ignores_preserve_single_line_blocks_being_off` | | `csharp_indent_labels` | `dotnet format whitespace` | No | Curb falls back to the documented default (`one_less_than_current`) for an unrecognised value. `dotnet format`'s own fallback for the same unrecognised value does not match its documented default either (it produces the `no_change` shape instead), so the two fallbacks disagree. | `IndentationTests.An_unrecognised_label_value_falls_back_to_the_default` | | `csharp_new_line_before_open_brace` | `dotnet format whitespace` | No | Same fallback-mismatch shape as `csharp_indent_labels`: Curb falls back to the documented default (`all`). `dotnet format` leaves the source untouched for the same unrecognised value — it silently skips applying the setting rather than falling back to its own documented default. | `NewLineBeforeOpenBraceTests.An_unrecognised_value_falls_back_to_the_default` | | `#pragma warning disable` (bare, or naming `IDE0055`) — not an `.editorconfig` key | `dotnet format whitespace` | No | Curb leaves a suppressed region unformatted, matching what IDE0055 itself would do. `dotnet format whitespace` is not diagnostic-driven — a plain Roslyn formatter pass with no concept of pragma suppression — so it always reformats the region regardless. Structural and permanent for any suppressed region that isn't already `dotnet format`-clean on its own. | `SuppressionTests.A_bare_disable_covers_every_rule_including_this_one` | | `tab_width` | `dotnet format whitespace` | No | Measured on `indent_style = tab` + `tab_width = 8` + a width narrow enough to force wrapping: `dotnet format` converts the outer two levels of tab indentation to four-space equivalents while leaving the wrapped argument lines as tabs — inconsistent, and only reproduced in this exact combination. Not fully root-caused; recorded as observed. `dotnet format` has nothing to check reflow width against otherwise, since it does not reflow at all. | `CoreOptionTests.Tab_width_counts_toward_the_line_length` | | `csharp_space_after_unary_operator` | `dotnet format whitespace` | No | A ReSharper generalized key `dotnet format` does not recognise at all. Measured: it always normalises `- x`/`+ x`/`! x` back to `-x`/`+x`/`!x` regardless of any `.editorconfig` setting — no configurable opinion there. Permanent for any file with a unary expression once the key is set. | `SpacingTests.Unary_minus_plus_and_not_take_a_space_when_asked` | | `csharp_space_after_unary_operator` | `dotnet format whitespace` | No | Same divergence, for the two unsafe pointer prefix operators (`*p`, `&x`) rather than unary minus/plus/not — `dotnet format` normalises `* p`/`& x` back just as unconditionally. | `SpacingTests.The_unsafe_pointer_prefix_operators_take_a_space_too` | | `csharp_space_around_ternary_operator` | `dotnet format whitespace` | No | A ReSharper generalized key `dotnet format` does not recognise at all. Measured: it always normalises `x > 0?x:0` back to `x > 0 ? x : 0` regardless of any `.editorconfig` setting — ternary `?`/`:` spacing is not configurable there. Permanent for any file with a ternary expression once the key is set to `false`. | `SpacingTests.The_ternary_operator_can_lose_its_surrounding_space` | | `csharp_space_around_ternary_operator` | `dotnet format whitespace` | No | Same divergence, on a ternary long enough to wrap under `max_line_length` — the wrap point itself is unaffected by the option, only the flat spacing `dotnet format` keeps re-adding is. | `SpacingTests.A_wrapped_ternary_still_breaks_without_the_space` | | `csharp_empty_block_style` | `ide0055` | No | Same direct conflict as the `dotnet format whitespace` row above, confirmed to reproduce under a real, analyzer-driven `dotnet build -p:EnforceCodeStyleInBuild=true` too, not just the `dotnet format whitespace` CLI. | `EmptyBlockStyleTests.Together_ignores_preserve_single_line_blocks_being_off` | | `csharp_indent_labels` | `ide0055` | No | Same fallback-mismatch divergence as the `dotnet format whitespace` row above, confirmed under a real `dotnet build -p:EnforceCodeStyleInBuild=true` too. | `IndentationTests.An_unrecognised_label_value_falls_back_to_the_default` | | `csharp_new_line_before_open_brace` | `ide0055` | No | Same fallback-mismatch divergence as the `dotnet format whitespace` row above, confirmed under a real `dotnet build -p:EnforceCodeStyleInBuild=true` too — expected, since IDE0055 is the same underlying Roslyn formatting engine. | `NewLineBeforeOpenBraceTests.An_unrecognised_value_falls_back_to_the_default` | | `tab_width` | `ide0055` | No | Same not-fully-root-caused divergence as the `dotnet format whitespace` row above, confirmed under a real `dotnet build -p:EnforceCodeStyleInBuild=true` too. | `CoreOptionTests.Tab_width_counts_toward_the_line_length` | | `csharp_space_after_unary_operator` | `ide0055` | No | Same permanent divergence as the `dotnet format whitespace` row above, confirmed under a real `dotnet build -p:EnforceCodeStyleInBuild=true` too. | `SpacingTests.Unary_minus_plus_and_not_take_a_space_when_asked` | | `csharp_space_around_ternary_operator` | `ide0055` | No | Same permanent divergence as the `dotnet format whitespace` row above, confirmed under a real `dotnet build -p:EnforceCodeStyleInBuild=true` too. | `SpacingTests.The_ternary_operator_can_lose_its_surrounding_space` | | `csharp_space_around_ternary_operator` | `ide0055` | No | Same divergence as the `dotnet format whitespace` row above, on the wrapped ternary, confirmed under a real `dotnet build -p:EnforceCodeStyleInBuild=true` too. | `SpacingTests.A_wrapped_ternary_still_breaks_without_the_space` | Two rows from the `dotnet format whitespace` table above do **not** carry over to `ide0055`: the bare `#pragma warning disable` case (`SuppressionTests.A_bare_disable_covers_every_rule_including_this_one`) and the unsafe pointer prefix operators (`SpacingTests.The_unsafe_pointer_prefix_operators_take_a_space_too`). Both are genuine fixed points of a real, analyzer-driven build — IDE0055 correctly respects a suppressed region the way `dotnet format whitespace`'s plain rewrite pass does not, and its pointer-prefix spacing opinion happens to already agree with Curb's.