From 201ff63c9dcbac4b037e35c1850eee83c2ae120d Mon Sep 17 00:00:00 2001
From: Dietmar Borgards <2646931+dborgards@users.noreply.github.com>
Date: Thu, 10 Sep 2026 23:18:17 +0200
Subject: [PATCH] build: fix the red net48 leg with Polyfill instead of a
 hand-rolled shim

`main` has been failing on windows-latest since #83 merged:

    DeferredEchoQueue.cs(46,43): error CS0305: Using the generic type
    'TaskCompletionSource<TResult>' requires 1 type arguments

#81 and #83 were both green and merged four minutes apart. #81 added
`DeferredEchoQueue`, which uses the non-generic `TaskCompletionSource`; #83
added the net48 leg that has to compile it. Neither pull request was ever
built against the other, because `strict_required_status_checks_policy` is
`false` on the `main` ruleset, so GitHub does not re-run a pull request's
checks when `main` moves underneath it.

The non-generic `TaskCompletionSource` is .NET 5+; netstandard2.0 and net48
have only `TaskCompletionSource<TResult>`.

Rather than growing the hand-rolled `TaskWaitAsyncPolyfill` a second shim,
this switches to the Polyfill package, which supplies both that type and
`Task.WaitAsync`, is maintained across 22 target frameworks, and is source
only (developmentDependency, no lib/) so it never becomes a dependency of
anything this repository ships. It also adds `global using global::Polyfills;`
itself, so no call site needs a using directive.

Polyfill's sources use C# 14 extension members, hence LangVersion 12 -> 14.
The language version is independent of the target frameworks, so the
netstandard2.0 assets are unchanged; the API approvals confirm it -- they do
not move.

Verified locally: net48 builds clean (0 warnings), the full solution builds
clean, 409/409 tests pass on net10.0, and `dotnet pack` produces no
PolyfillTargetsForNuget warning since the reference is scoped to the test
project.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 Directory.Build.props                         |  9 +-
 Directory.Packages.props                      |  7 ++
 .../Infrastructure/TaskWaitAsyncPolyfill.cs   | 99 -------------------
 tests/Directory.Build.props                   | 10 ++
 4 files changed, 25 insertions(+), 100 deletions(-)
 delete mode 100644 tests/CanKit.Pro.Tests/Infrastructure/TaskWaitAsyncPolyfill.cs

diff --git a/Directory.Build.props b/Directory.Build.props
index f075630..5303493 100644
--- a/Directory.Build.props
+++ b/Directory.Build.props
@@ -13,7 +13,14 @@
   </PropertyGroup>
 
   <PropertyGroup Label="Language">
-    <LangVersion>12</LangVersion>
+    <!--
+      C# 14 rather than 12 because the Polyfill package's sources use extension members
+      (`extension(Byte) { ... }`), and those do not parse below 14. Nothing in this repository
+      relies on a 13/14 feature otherwise; raising the ceiling does not change how the existing
+      code compiles, and the language version is independent of the target frameworks, so the
+      netstandard2.0 assets are unaffected.
+    -->
+    <LangVersion>14</LangVersion>
     <Nullable>enable</Nullable>
     <ImplicitUsings>disable</ImplicitUsings>
     <EnableNETAnalyzers>true</EnableNETAnalyzers>
diff --git a/Directory.Packages.props b/Directory.Packages.props
index 100bb21..ec7af7f 100644
--- a/Directory.Packages.props
+++ b/Directory.Packages.props
@@ -30,6 +30,13 @@
     -->
     <PackageVersion Include="FluentAssertions" Version="6.12.2" />
     <PackageVersion Include="coverlet.collector" Version="10.0.1" />
+    <!--
+      Polyfill supplies the BCL APIs the test suite uses but netstandard2.0/net48 lack:
+      the non-generic TaskCompletionSource and Task.WaitAsync among them. It is a source-only package
+      (developmentDependency, no lib/), so it compiles in and never becomes a dependency of
+      anything. It requires LangVersion 14; see the Language block in Directory.Build.props.
+    -->
+    <PackageVersion Include="Polyfill" Version="11.3.0" />
     <!--
       PublicApiGenerator renders the approved public-API surface (see PublicApiSurfaceTests). It is
       a test-only tool, never a dependency of a shipped package, so it carries PrivateAssets="all"
diff --git a/tests/CanKit.Pro.Tests/Infrastructure/TaskWaitAsyncPolyfill.cs b/tests/CanKit.Pro.Tests/Infrastructure/TaskWaitAsyncPolyfill.cs
deleted file mode 100644
index 453a5cf..0000000
--- a/tests/CanKit.Pro.Tests/Infrastructure/TaskWaitAsyncPolyfill.cs
+++ /dev/null
@@ -1,99 +0,0 @@
-#if !NET
-
-// The polyfill deliberately lives in System.Threading.Tasks rather than in
-// CanKit.Pro.Tests.Infrastructure. `Task.WaitAsync` is the one .NET 6+ API this suite leans on
-// heavily — 43 call sites across seven files — and every one of them already has
-// `using System.Threading.Tasks;` at the top because it is awaiting a Task in the first place.
-// Putting the extensions in that namespace means the net48 leg compiles the existing call sites
-// unchanged: no `#if` at a single assertion, no extra using that only one TFM needs, and a test
-// written tomorrow in a file that has never heard of this class still builds on both legs.
-namespace System.Threading.Tasks;
-
-/// <summary>
-/// <c>Task.WaitAsync</c> for the <c>net48</c> leg of the suite. The method arrived in .NET 6 and
-/// is absent from .NET Framework, so without it the second target framework could not compile at
-/// all — see <c>tests/Directory.Build.props</c> for why that target framework exists.
-/// </summary>
-/// <remarks>
-/// The observable contract is copied from the framework's own, because tests assert against it:
-/// the timeout overload throws <see cref="TimeoutException"/> and the cancellation overload
-/// throws <see cref="OperationCanceledException"/>, and in both cases the awaited task is left
-/// running rather than cancelled — <c>WaitAsync</c> bounds the *wait*, not the work.
-/// </remarks>
-internal static class TaskWaitAsyncPolyfill
-{
-    public static async Task WaitAsync(this Task task, TimeSpan timeout)
-    {
-        await BoundAsync(task, timeout).ConfigureAwait(false);
-        await task.ConfigureAwait(false);
-    }
-
-    public static async Task<TResult> WaitAsync<TResult>(this Task<TResult> task, TimeSpan timeout)
-    {
-        await BoundAsync(task, timeout).ConfigureAwait(false);
-        return await task.ConfigureAwait(false);
-    }
-
-    public static async Task WaitAsync(this Task task, CancellationToken cancellationToken)
-    {
-        await BoundAsync(task, cancellationToken).ConfigureAwait(false);
-        await task.ConfigureAwait(false);
-    }
-
-    public static async Task<TResult> WaitAsync<TResult>(this Task<TResult> task, CancellationToken cancellationToken)
-    {
-        await BoundAsync(task, cancellationToken).ConfigureAwait(false);
-        return await task.ConfigureAwait(false);
-    }
-
-    // Returns once `task` has completed, or throws if the bound was reached first. The caller
-    // then awaits `task` itself, which is what propagates its result or its exception with the
-    // stack trace intact — re-throwing from here would bury it.
-    private static async Task BoundAsync(Task task, TimeSpan timeout)
-    {
-        if (task.IsCompleted)
-        {
-            return;
-        }
-
-        // The delay is cancelled on the happy path. A pending Task.Delay holds a timer entry
-        // until it fires, and a suite with hundreds of five-second bounds would otherwise keep
-        // every one of them alive to the end of the run.
-        using (var delayCancellation = new CancellationTokenSource())
-        {
-            var delay = Task.Delay(timeout, delayCancellation.Token);
-            var finished = await Task.WhenAny(task, delay).ConfigureAwait(false);
-            if (!ReferenceEquals(finished, task))
-            {
-                throw new TimeoutException("The operation has timed out.");
-            }
-
-            delayCancellation.Cancel();
-        }
-    }
-
-    private static async Task BoundAsync(Task task, CancellationToken cancellationToken)
-    {
-        if (task.IsCompleted)
-        {
-            return;
-        }
-
-        cancellationToken.ThrowIfCancellationRequested();
-
-        // RunContinuationsAsynchronously keeps the continuation off the thread that cancels the
-        // token: without it, whatever called Cancel() would run the rest of the awaiting test
-        // inline, which on a token cancelled from a timer means test code on a timer thread.
-        var cancelled = new TaskCompletionSource<bool>(TaskCreationOptions.RunContinuationsAsynchronously);
-        using (cancellationToken.Register(state => ((TaskCompletionSource<bool>)state).TrySetResult(true), cancelled))
-        {
-            var finished = await Task.WhenAny(task, cancelled.Task).ConfigureAwait(false);
-            if (!ReferenceEquals(finished, task))
-            {
-                throw new OperationCanceledException(cancellationToken);
-            }
-        }
-    }
-}
-
-#endif
diff --git a/tests/Directory.Build.props b/tests/Directory.Build.props
index eff5013..00858c7 100644
--- a/tests/Directory.Build.props
+++ b/tests/Directory.Build.props
@@ -56,6 +56,16 @@
     <PackageReference Include="PublicApiGenerator">
       <PrivateAssets>all</PrivateAssets>
     </PackageReference>
+    <!--
+      Source-only: `compile` brings the polyfill sources in, `contentfiles` is how they are
+      delivered, and `build` supplies the .targets that sets the per-TFM DefineConstants deciding
+      which of them apply. The package adds `global using global::Polyfills;` itself, so the
+      extension-method polyfills need no using directive at any call site.
+    -->
+    <PackageReference Include="Polyfill">
+      <PrivateAssets>all</PrivateAssets>
+      <IncludeAssets>compile; build; analyzers; contentfiles</IncludeAssets>
+    </PackageReference>
     <!--
       coverlet.collector 10.x ships build assets for net8.0 and newer only; there is nothing in it
       for a .NET Framework test host. Referencing it there would put an unusable collector on the