some tests fail with unicode-width v0.1.13

[decathorpe]

Versions 0.1.12 and 0.1.13 of the unicode-width crate changes its behaviour to be more in line with the Unicode standard, but it looks like many projects (especially test suites) relied on the old behaviour - including delta.

Upstream does not consider the behaviour change a breaking change:
unicode-rs/unicode-width#55

Trying to build git-delta v0.17.0 and running its tests for Fedora Linux, I get the following failures with unicode-width v0.1.13:

failures:
---- ansi::tests::test_measure_text_width stdout ----
thread 'ansi::tests::test_measure_text_width' panicked at src/ansi/mod.rs:205:9:
assertion `left == right` failed
  left: 4
 right: 2
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- features::side_by_side::tests::test_two_plus_lines_exact_fit stdout ----
thread 'features::side_by_side::tests::test_two_plus_lines_exact_fit' panicked at src/wrapping.rs:469:9:
assertion `left == right` failed: syntax and diff wrapping differs (-) [*r*]
  left: (1, 2)
 right: (1, 3)
---- features::line_numbers::tests::test_line_numbers_continue_correctly_after_wrapping stdout ----
thread 'features::line_numbers::tests::test_line_numbers_continue_correctly_after_wrapping' panicked at src/tests/integration_test_utils.rs:150:9:
assertion `left == right` failed: on line 3 of input:
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
a/a.py ⟶   b/b.py
──────────────────────────────────────────
───┐
1: │
───┘
│  1 │abc            │  1 │abc
│  2 │a = one side   │  2 │a = one longer@
│    │               │    │ side
│  3 │xyz            │  3 │xyz
▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲
  left: "│    │               │    │         > side"
 right: "│    │               │    │ side"
---- wrapping::tests::test_alignment_1_line_vs_3_lines stdout ----
thread 'wrapping::tests::test_alignment_1_line_vs_3_lines' panicked at src/wrapping.rs:469:9:
assertion `left == right` failed: syntax and diff wrapping differs [*l*] (r)
  left: (0, 2)
 right: (0, 1)
---- wrapping::tests::test_alignment_2_lines_vs_3_lines stdout ----
thread 'wrapping::tests::test_alignment_2_lines_vs_3_lines' panicked at src/tests/integration_test_utils.rs:150:9:
assertion `left == right` failed: on line 2 of input:
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
a ⟶   b
───────────────────────────────────────────────────────
───┐
1: │
───┘
│  1 │.........1.........2< │  1 │.........1.........2+
│    │               >....  │    │.........3.........4+
│    │                      │    │.........5.........6
▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲
  left: "│    │                >.... │    │.........3.........4+"
 right: "│    │               >....  │    │.........3.........4+"
---- wrapping::tests::test_wrap_line_newlines stdout ----
thread 'wrapping::tests::test_wrap_line_newlines' panicked at src/wrapping.rs:873:13:
assertion `left == right` failed
  left: [[(Style { <aeorSd> }, "012"), (Style { <aEorsd> }, "34"), (Style { <aeorsd> }, "<")], [(Style { <aeorsd> }, "   "), (Style { <aeorsd> }, ">"), (Style { <aEorsd> }, "5\n")]]
 right: [[(Style { <aeorSd> }, "012"), (Style { <aEorsd> }, "345\n")]]
failures:
    ansi::tests::test_measure_text_width
    features::line_numbers::tests::test_line_numbers_continue_correctly_after_wrapping
    features::side_by_side::tests::test_two_plus_lines_exact_fit
    wrapping::tests::test_alignment_1_line_vs_3_lines
    wrapping::tests::test_alignment_2_lines_vs_3_lines
    wrapping::tests::test_wrap_line_newlines
test result: FAILED. 372 passed; 6 failed; 8 ignored; 0 measured; 0 filtered out; finished in 0.91s

So it looks like the tests will need to be adapted for the changes in unicode-width.

For example, the \u{1} character can no longer be assumed to have width 0. Replacing it with a zero-width space might work, as seen here: ratatui/ratatui#1171

[th1000s]

Nice, a package maintainer provided an essential hint long before the first reported panic, see #1726. But cargo install not defaulting to --locked, or at least performing or checking for a successful cargo test run somewhere and blindly trusting some semver definition is the real culprit.