fix(xtext.ui): iterate a snapshot of the matches when showing a running search

[joaodinissf]

Problem

FastReferenceSearchResultContentProvider.inputChanged repopulates the view by iterating the live ReferenceSearchResult.getMatchingReferences() list. That is the internal ArrayList that the search job's accept() appends to without a lock. If a search that is still running is shown, for example re-selected from the search history, the iteration can race the search thread. The ConcurrentModificationException then escapes viewer.setInput(...) and leaves the page half-initialised: the listener is registered, but the view is not populated.

Who is affected: DDK's own languages use Xtext's default content provider, which has the same live iteration. This provider is used by products built on DDK that bind it.

Fix

Iterate a copy (Lists.newArrayList(...)) and skip null elements. The copy itself is unsynchronised, so it can observe a slot the search thread has reserved but not yet published.

This removes the exception. It narrows the race rather than eliminating it: a reference can still be missed or shown twice at the boundary, and the related races in this provider are tracked separately.

Test

FastReferenceSearchResultContentProviderTest is registered in XtextUiTestSuite. A mocked IResourceDescriptions appends a reference to the live list while inputChanged is iterating it, which simulates the search thread deterministically. The test fails on master with ConcurrentModificationException and passes with the fix.

Local run: full mvn clean verify passes apart from failures that also occur on master in this environment; checkstyle and PMD are clean.

Found by the formal models of the find-references batching in #1549 (formal/BUGS.md, REF-2): both the TLA+ and the Lean model reach it, and 3/3 independent reviewers upheld it.

🤖 Generated with Claude Code