Add .NET 10 compatibility support

[Frank Shearar (frankshearar)]

No description provided.

[Akash Lal (akashlal)]

There are a few additional concurrency APIs/contracts worth covering before declaring .NET 10 support. Comparing the .NET 8, 9, and 10 reference surfaces with the replacements in this PR shows these gaps (including .NET 9 additions that .NET 10 applications can use):

Area	Gap	Requested handling
Small-integer atomics	Interlocked.Exchange and CompareExchange overloads for byte, sbyte, short, and ushort were added in .NET 9, but have no Coyote replacements.	Add controlled replacements with scheduling points, consistent with the existing integer atomics, or explicitly diagnose them as unsupported. Leaving these calls native loses the exploration opportunities provided for other atomics.
Generic atomics	Since .NET 9, Interlocked.Exchange<T> and CompareExchange<T> accept primitive and enum types as well as reference types. Coyote's replacements still require where T : class.	Update the replacement contracts and cover primitive/enum instantiations. This is more than a missing overload: matching the existing signature can redirect a valid application call to a replacement with incompatible generic constraints.
Memory barriers	.NET 10 added Volatile.ReadBarrier() and WriteBarrier(). Neither appears in the replacements or the API gate.	Explicitly classify their behavior under Coyote's memory model. Native pass-through may be appropriate, but it should be a deliberate, documented decision rather than an unexamined gap.
Named wait handles	.NET 10 added constructors/opening overloads using NamedWaitHandleOptions; the new EventWaitHandle constructors are absent from Coyote's creation wrappers.	Audit the boundary and clearly reject unsupported cross-process synchronization. Existing name-based rejection covers some opening methods, but not these constructors. This does not require implementing cross-process model checking.

The generic Interlocked contract change also illustrates why the API audit needs to include changed constraints/semantics, not just newly named methods.

I would ask this PR to address the two atomic gaps and explicitly classify the barrier and wait-handle boundaries. I would not require modeling every new async library feature (async ZIP APIs, JSON-over-pipelines, async LINQ); those can follow the existing external-library/uncontrolled-operation policy. Similarly, the absence of wrappers for TaskCompletionSource.SetFromTask alone does not establish a scheduling defect, since its input must already be completed.

These are coverage findings from inspection, not yet reproduced runtime failures like the previously discussed WaitAsync and WaitAll cases.

[Akash Lal (akashlal)]

Three additional review findings, separate from the runtime API coverage gaps:

[P1] Preserve the first completion event in WaitAsync

Location: Source/Test/Rewriting/Types/Threading/Tasks/Task.cs, shared CreateWaitAsyncTask helper (around lines 389-405).

The helper chooses cancellationTask.IsCanceled ? cancellationTask : task based on the state when the helper operation runs, rather than recording which event completed the wait first. I reproduced this with a default TaskCompletionSource<int>:

using var cts = new CancellationTokenSource();
var source = new TaskCompletionSource<int>();
Task<int> wait = source.Task.WaitAsync(cts.Token);
source.SetResult(42);
cts.Cancel();
Assert.Equal(42, await wait);

Native .NET 10 returns 42; the controlled version fails with TaskCanceledException when the helper runs after both events. The shared helper affects generic and non-generic overloads, so this can produce false bugs in both.

Please record the completion/cancellation winner when the event occurs, and add a regression where source completion precedes cancellation without an intervening await.

[P1] Observe cancellation while enumerable WaitAll is blocked

Location: Source/Test/Rewriting/Types/Threading/Tasks/Task.cs, enumerable overload (around lines 724-728) and shared array implementation (around lines 736-761); TaskServices.WaitUntilAllTasksComplete.

The new overload delegates to the array implementation, whose controlled wait resumes only when all tasks complete. The cancellation check before entering the wait does not handle cancellation occurring afterward.

using var cts = new CancellationTokenSource();
var pending = new TaskCompletionSource<int>();
Task canceler = Task.Run(() => cts.Cancel());
Assert.ThrowsAny<OperationCanceledException>(() =>
    Task.WaitAll((IEnumerable<Task>)new Task[] { pending.Task }, cts.Token));
canceler.GetAwaiter().GetResult();

Native .NET 10 throws OperationCanceledException. Coyote can instead report a deadlock when the wait begins before the cancellation operation executes, because the incomplete task prevents the wait predicate from becoming true.

The underlying array-path limitation predates this PR, but the newly supported enumerable overload exposes it. Please include cancellation in the controlled wake-up condition and cover cancellation after the wait starts, not just an already-canceled token.

[P2] Discover the runtime API surface independently of its classifications

Location: Tests/Tests.Rewriting/Types/RuntimeApiDiffGateTests.cs, GetRuntimeMembers (around lines 133-195).

GetRuntimeMembers() manually lists the signatures to inspect, and the supported/unsupported classifications are derived from that same list. A newly added runtime overload never enters the input, so the gate remains green without requiring a classification.

The synthetic added-method test checks the classifier by manually appending a fabricated signature; it does not check runtime discovery. Even the WhenEach and span-based task overloads supported by this PR are absent from the list.

Please discover the explicitly audited runtime types/API families independently, then compare that surface against explicit supported/unsupported classifications. A regression should demonstrate that an unclassified member found through the discovery path fails the gate. This need not classify the entire BCL.

The two P1 issues above were reproduced against native .NET 10; the P2 finding is established by inspection of the gate.

[Frank Shearar (frankshearar)]

Frank the Clank says: the review findings from Akash Lal (@akashlal) in the API coverage comment and the correctness and gate comment are addressed in the commits below. Each was first reproduced as a failing test against the previous code where applicable. PR head is now df9ac266. Coyote CI run 38024569802 passes on that head: build/test and samples on Windows, Ubuntu and macOS, plus license/cla.

#	Finding	Change	Commit
1	[P1] WaitAsync first event	Cancellation no longer replaces a source outcome that was already delivered. Your SetResult(42), Cancel() reproducer now returns 42, and the non-generic form completes. Sources with RunContinuationsAsynchronously can still lose to a later cancellation, as native .NET does. Tests compare controlled results with native .NET for result/fault/source-cancel, in both orders, for both task forms.	a7245785
2	[P1] Blocked WaitAll cancellation	The controlled wait wakes on cancellation as well as completion. It throws for the wait token and leaves pending tasks incomplete. Tests start the wait before cancelling (array and IEnumerable overloads) and compare completion-versus-cancellation ordering with native .NET. Waits with a token that is never cancelled still report deadlocks.	ea5dcf16, 5dcbb54b
3	Small-integer atomics	Exchange/CompareExchange for byte/sbyte/short/ushort are controlled scheduling points on .NET 9+. Tests include lost-update contention that is only found through those points.	1266433d
4	Generic atomics	On .NET 9+ the generic replacements drop where T : class and delegate type validation to the runtime. Explicit <object>/<int>/byte- and long-enum calls match native .NET, and <DateTime> throws the same NotSupportedException. Older targets keep the class constraint. Before this fix, ilverify reported unsatisfied constraints for these calls.	1266433d
5	Volatile barriers	These are deliberate native pass-through with no scheduling point, the same as Thread/Interlocked.MemoryBarrier. Coyote does not explore weak-memory reorderings. Documented in binary-rewriting.md and the assessment; the API gate classifies both with a reason.	a99851a0
6	Named wait handles	During systematic testing, every name-bearing EventWaitHandle constructor, including the NamedWaitHandleOptions overloads, is rejected before any OS event is created or opened. A null name, and an empty name on Windows, stay controlled; on Unix the runtime itself rejects an empty name. Opening methods, Mutex and Semaphore remain reported as uncontrolled. Cross-process model checking is out of scope.	17e37708, df9ac266
7	[P2] Independent API discovery	The gate now discovers the audited families by reflection, independently of their classifications. Signatures include constructors, generic arity and constraints, and ref/out. Each member needs exactly one classification per framework: controlled, rejected (with reason) or pass-through (with reason). Unclassified, missing, overlapping and stale entries fail. A fixture with an extra overload fails through the real discovery path, and WhenEach and the span overloads are discovered. Discovery found and fixed Monitor.TryEnter(object, int), Task.Wait(TimeSpan, CancellationToken) and the .NET Framework EventWaitHandleSecurity constructor.	d075d2a7

Also included: a merge of origin/main, which keeps Monitor.SynchronizedBlock.ResetCache (#510); refreshed rewriting snapshots; and a dated addendum to NET10-COMPATIBILITY-ASSESSMENT.md. Locally on Windows, Scripts/run-tests.ps1 -ci, the compatibility matrix and the net10.0/net8.0 package smoke tests passed.

Not changed, per your guidance: async ZIP, JSON-over-pipelines and async LINQ stay under the existing external-library policy, and no SetFromTask wrappers were added. This needs your re-review; I am not marking anything as approved.

[cdb:ri_mv1nmbnv_0000005_17bb2b0c07a4/respond]