Fix NullReferenceException in TextLeadingPrefixCharacterEllipsis when collapsing an unbreakable cluster

[Symbai]

What does the pull request do?

Fixes a latent NullReferenceException in TextLeadingPrefixCharacterEllipsis.Collapse (the PrefixCharacterEllipsis text-trimming mode). When the suffix portion of a collapsed line ends in an unbreakable cluster, a ligature, or a base character with combining marks, shaped as a single glyph cluster, the code dereferences a null split result and crashes.

What is the current behavior?

While building the trailing suffix of an ellipsized line, Collapse calls endShapedRun.Split(run.Length - suffixCount) and unconditionally uses splitSuffix.Second!:

var splitSuffix = endShapedRun.Split(run.Length - suffixCount);
collapsedRuns.Add(splitSuffix.Second!);

Since #21351, ShapedTextRun.Split returns (first, null) - rather than throwing - when the requested split position falls inside an unbreakable cluster that reaches the end of the run. In that case splitSuffix.Second is null, and splitSuffix.Second! throws a NullReferenceException, crashing layout/rendering.

What is the updated/expected behavior with this PR?

When the suffix run cannot be split because it is a single unbreakable cluster, the whole run is kept as the suffix instead of crashing, which is the correct outcome, since an indivisible cluster is an all-or-nothing unit:

var splitSuffix = endShapedRun.Split(run.Length - suffixCount);
collapsedRuns.Add(splitSuffix.Second ?? splitSuffix.First!);

To test: apply TextTrimming.PrefixCharacterEllipsis to text whose trailing portion is a single unbreakable cluster, in a width that forces collapsing. Before this PR it crashes; after it, the line collapses normally with the cluster preserved as the suffix.

How was the solution implemented (if it's not obvious)?

The fix is a single defensive null-coalesce. ShapedTextRun.Split always returns a non-null First (the whole run when no further split is possible), so falling back to splitSuffix.First is safe and complete. This mirrors the pattern already used by TextFormatterImpl.SplitTextRuns, which null-checks split.Second before consuming it.

No unit test is included: reproducing this branch end-to-end requires a font that produces multi-character clusters (e.g. Thai combining marks). The only such font in the test assets is the monospace Cascadia Code, and with a monospace font the widths required to reach this branch are mutually exclusive, it would need a proportional cluster-capable font, which the test project does not ship.

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

None.

Obsoletions / Deprecations

None.

[avaloniaui-bot]

You can test this PR using the following package version. 12.1.999-cibuild0065447-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[Gillibald]

There is no matching unit test that covers the failing scenario. Please add a unit test.

[Symbai]

@Gillibald reproducing this branch end-to-end requires a font that produces multi-character clusters (e.g. Thai combining marks). The only such font in the test assets is the monospace Cascadia Code, and with a monospace font the widths required to reach this branch are mutually exclusive, it would need a proportional cluster-capable font, which the test project does not ship.

[MrJul]

it would need a proportional cluster-capable font, which the test project does not ship.

Feel free to add any font needed to the test project (as long as the license allows it).