Skip to content

Bump the tests group with 6 updates - #335

Closed
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/nuget/dot-config/tests-9f4225e6aa
Closed

Bump the tests group with 6 updates#335
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/nuget/dot-config/tests-9f4225e6aa

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jul 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Updated CancelCop.Analyzer from 1.27.173 to 1.38.0.

Release notes

Sourced from CancelCop.Analyzer's releases.

1.38.0

New rule: CC036 — blocking Socket calls in async code

A socket call blocks until the network responds — or until a TCP timeout that can run into minutes. Inside async code that parks a thread-pool thread on a remote party's behaviour, the least predictable thing a server waits on. Accept and Connect are worse still: they can block indefinitely, with no data to wait for.

// ❌ CC036
public async Task ServeAsync(Socket listener)
{
    var client = listener.Accept();
}

// ✅
var client = await listener.AcceptAsync(cancellationToken);

Covers Receive, ReceiveFrom, ReceiveMessageFrom, Send, SendTo, SendFile, Accept, Connect, Disconnect.

Why this is a separate rule, not an extension of CC028

CC028 covers blocking System.IO calls including every Stream, so a NetworkStream is already handled there — and CC036 stays quiet on it.

CC028 can offer a code fix only because it requires the async counterpart to be signature-compatible: the same parameters, optionally plus a token. Socket's async APIs are not shaped that way — Receive(byte[]) pairs with ReceiveAsync(Memory<byte>, CancellationToken), and Accept() with AcceptAsync(CancellationToken) returning a different type. Loosening CC028's matching to reach them would give up exactly the property that makes its rewrites safe. So CC036 stands apart, and is analyzer-only because no mechanical rewrite exists.

Conservative by design

  • Verified against the shipped analyzer first: a blocking Socket.Receive in async code produced zero diagnostics from all 35 existing rules.
  • Socket is resolved from the compilation and matched by symbol, through the override chain.
  • The named counterpart must exist on the target framework — SendFileAsync is absent on .NET Standard 2.0, and recommending it there would suggest a call that does not compile.
  • Non-blocking sockets are exempt. socket.Blocking = false makes the synchronous calls return immediately. The assigned member is resolved to Socket.Blocking by symbol (object initializers and unqualified inherited assignments count; an unrelated property of the same name does not), only a plain = counts, the scan stops at nested functions, and only the last assignment before the call is in effect.

987 tests passing (was 970). 36 diagnostics.

1.37.0

New rule: CC035 — cancellation silently swallowed by an empty catch

Cancellation is reported by an exception precisely so the caller learns the work did not finish. An empty catch discards that signal: execution continues past the try as though the operation succeeded, and downstream code acts on results that were never produced.

// ❌ CC035 (Info) — the caller cannot tell the save did not happen
try
{
    await SaveAsync(cancellationToken);
}
catch (OperationCanceledException)
{
}

Complements CC019

CC019 covers a broad catch — catch or catch (Exception) — that swallows cancellation among everything else. A clause naming the cancellation type explicitly is outside its scope, yet it is the more deliberate-looking version of the same defect. Verified against the shipped analyzer before the rule was written: zero diagnostics from all 34 existing rules on this shape.

Scoped to the empty body

Catching cancellation to stop quietly is a real pattern at a boundary, and such handlers do something. The rule stays quiet for any statement, a when filter, a rethrow — or a comment recording the intent, so the idiomatic wait-until-cancelled handler is clean:

catch (TaskCanceledException)
{
    // expected on shutdown
}

That exemption came from the repository's own clean-code guard, which caught the rule firing on exactly this pattern during development. A documented discard is not a silent one.

TaskCanceledException and other subclasses are covered, and the framework exception is matched by symbol — source that declares its own System.OperationCanceledException is not mistaken for it.

Info severity (a deliberate silent stop is unusual but legitimate) and analyzer-only (the right resolution depends on what the caller needs to know).

970 tests passing (was 959). 35 diagnostics.

1.36.0

New rule: CC034 — ParallelOptions missing a CancellationToken

ParallelOptions.CancellationToken is the only way to cancel a Parallel loop. Without it the loop runs every partition to completion no matter what the caller wants — and a long parallel loop over a large collection is precisely the work most worth stopping.

// ❌ CC034 — nothing can stop this loop
var options = new ParallelOptions { MaxDegreeOfParallelism = 4 };
Parallel.ForEach(items, options, Handle);

// ✅ fix (adds to the existing initializer, keeping what was already set)
var options = new ParallelOptions
{
    MaxDegreeOfParallelism = 4,
    CancellationToken = cancellationToken,
};

CC002 structurally cannot see this

CC002 fires on a call with a token-accepting overload. Here the token is neither an argument nor an overload — it's a property in an object initializer, and Parallel.ForEach has no token-taking overload at all.

Verified empirically before the rule was written: a probe project referencing the shipped analyzer produced zero diagnostics from all 33 existing rules on this shape.

When it stays quiet

  • no token in scope — nothing to suggest
  • the token is set in the initializer, or assigned to the options before the loop
  • the options are held in a field or property, configured the same way

When it still reports

A token that cannot cancel is not "set": default, CancellationToken.None, new CancellationToken(), new CancellationToken(false). Nor is an assignment that does not reach the loop:

  • placed after the loop, or inside a lambda that may never run
  • conditional relative to the use — inside an if, switch, loop, conditional expression, or short-circuit whose branch does not contain the loop (when creation, assignment and loop share a branch, it is accepted)
  • overwritten before the loop — only the last write counts
  • configuring a different object: this.options and other.options share a field symbol, so the receiver is matched too

The fix

Appends to an existing initializer rather than replacing it, drops the now-redundant empty argument list, re-escapes keyword parameter names, and adds no import — the identifier is already in scope, and using System.Threading; could make an existing custom CancellationToken ambiguous (CS0104).

959 tests passing (was 929). 34 diagnostics.

1.35.0

Fixed: CC001's code fix on an async iterator

CC001 has always covered async iterators, but its fix added a bare CancellationToken. On an iterator that token is ignored by the compiler-generated GetAsyncEnumerator, so a consumer's .WithCancellation(token) silently fails to reach it — which is precisely what CC011 reports.

Applying CC001's fix to an async iterator therefore:

  1. resolved CC001,
  2. immediately raised CC011, and
  3. left the stream just as uncancellable as before.
// before — CC001's fix produced this, and CC011 then fired
public async IAsyncEnumerable<int> ReadAsync(CancellationToken cancellationToken = default)

// after
public async IAsyncEnumerable<int> ReadAsync(
    [EnumeratorCancellation] CancellationToken cancellationToken = default)

The System.Runtime.CompilerServices import comes with it. A regression test runs CC011 over CC001's fixed output, which is the direct expression of "the two rules now agree".

Precisely scoped

  • Only iterators returning IAsyncEnumerable<T>, checked semantically. CC001 also covers iterators returning IAsyncEnumerator<T>, where the attribute has no effect and produces CS8424 — breaking any project that treats warnings as errors.
  • An ordinary async method still gets a plain token; [EnumeratorCancellation] on a non-iterator is CS8205.
  • A yield inside a nested local function belongs to that function's iterator, not the enclosing method.
  • The attribute is emitted root-qualified with a simplifier annotation, so it reads as [EnumeratorCancellation] in ordinary code but cannot be captured by a consumer's own EnumeratorCancellationAttribute or a nested System namespace.

929 tests passing (was 921). No diagnostic IDs or severities changed — 33 diagnostics.

1.34.0

New rule: CC033 — CancellationTokenSource field never disposed

A source owns a timer (once a delay is set) and a registration list that every linked token and every Register callback adds to. A field keeps that alive for the whole lifetime of the owning object.

Linked sources are worse: an undisposed child stays attached to its parent's callback list, so a long-lived parent accumulates every child ever created.

// ❌ CC033 — created by this type, never disposed
public class Worker
{
    private readonly CancellationTokenSource _cts = new();
}

// ✅ the owner disposes what it created
public sealed class Worker : IDisposable
{
    private readonly CancellationTokenSource _cts = new();
    public void Dispose() => _cts.Dispose();
}

Complements CC014

CC014 owns the local case, where the fix is mechanical — make it a using declaration. A field's lifetime is the object's, so the resolution is to implement IDisposable and let the owner's disposal cascade. That's a design change, so CC033 is analyzer-only.

Ownership is the gate

Fires only when the declaring type creates the source — including new(), a parenthesized or cast creation, a conditional (enabled ? new() : new()), CreateLinkedTokenSource, and CTS subclasses. An injected source belongs to whoever created it, and demanding its disposal would be actively harmful.

Exonerating: disposal anywhere in the type — _cts.Dispose(), this._cts.Dispose(), _cts?.Dispose(), (_cts!).Dispose(), ((IDisposable)_cts).Dispose(), using (_cts) { } — plus escape by return, argument, local alias, or assignment (including through a conditional or ??), and static fields.

Not exonerating: naming Dispose without calling it (Action cleanup = _cts.Dispose;), an extension method spelled Dispose/DisposeAsync (CTS has no instance DisposeAsync, so every such call is an extension), and a subclass that hides Dispose with a no-op — CancellationTokenSource.Dispose() is not virtual.

Implementation note

Built on a symbol-start action, so the whole type — every member, every partial declaration — is seen while each nested node action arrives with the semantic model for its own tree, rather than reaching for Compilation.GetSemanticModel (RS1030).

Two clean-code samples changed

AllAnalyzersCleanCodeTests had two samples creating a CTS field and never disposing it. They predate this rule and genuinely leak — the same defect CA2213 catches — so the samples now dispose what they create.

921 tests passing (was 893). 33 diagnostics.

1.33.0

New rule: CC032 — async call not awaited in non-async code

A dropped task cannot be cancelled, cannot be waited on at shutdown, and its failure is never observed — the exception surfaces later on an unrelated thread, or nowhere at all. Work started this way outlives the request or host that started it: the same class of problem as a token that is never passed.

The gap this fills

CS4014 only fires inside an async method. In a constructor, a synchronous method, or a non-async lambda — exactly where the mistake is easiest to make, because there is no await to reach for — the compiler says nothing at all.

// ❌ CC032 — a constructor cannot be async, so CS4014 never fires
public Service()
{
    InitializeAsync();
}

CC032 covers that gap and defers to the compiler everywhere CS4014 already reports, so the two never double up.

Covered forms

  • bare expression statements, and null-conditional calls (worker?.StartAsync();) — the diagnostic underlines the whole expression, not the fragment after the ?.
  • expression-bodied members that return void, and void-returning expression-bodied lambdas
  • Task subclasses and type parameters constrained to Task
  • discarded ConfigureAwait results, and discarded awaiters (SaveAsync().GetAwaiter();, including the nested configured awaiters) — the compiler warns about none of these in any context, so they are reported inside async methods too

Not flagged

  • tasks that are assigned, returned, or passed as an argument
  • _ = SaveAsync() — the documented way to say "I know, and I mean it"; a rule that flagged the opt-in would be impossible to satisfy
  • lambdas converted to Task-returning delegates, which hand the task to their caller
  • expression-tree lambdas, whose body is data and never runs
  • an async lambda converted to void — that is CC024's finding

Framework types are matched by identity: a user's nested Outer.TaskAwaiter, or a Task subclass named TaskAwaiter, is not mistaken for the framework type.

Analyzer-only

The right resolution — make the caller async and await, hand the task to something that observes it, or opt in deliberately — depends on intent. Same choice as CC017, CC020, CC024, CC027, CC031.

893 tests passing (was 867). 32 diagnostics.

1.32.0

New rule: CC031 — blocking synchronization primitives in async code

ManualResetEventSlim.Wait, CountdownEvent.Wait, WaitHandle.WaitOne/WaitAll/WaitAny, Monitor.Wait, and Thread.Join park a thread-pool thread until another thread signals.

In async code that is the worst kind of blocking: the wait is unbounded, it consumes a pooled thread that the continuations it is waiting for may themselves need, and under load it can deadlock the pool outright. None of them observes a CancellationToken by default, so shutdown and request abort cannot reclaim the thread.

// ❌ CC031 — the classic "block until cancelled" trap
public async Task RunAsync(CancellationToken cancellationToken)
{
    cancellationToken.WaitHandle.WaitOne();
    await Task.Yield();
}

// ✅ await a task that completes on cancellation
await Task.Delay(Timeout.Infinite, cancellationToken);

Analyzer-only by design

Unlike the rest of the blocking-in-async family (CC013, CC015, CC026, CC028, CC030), these primitives have no …Async counterpart in .NET. Resolving the finding means changing the design — a SemaphoreSlim awaited with WaitAsync, a TaskCompletionSource signalled instead of an event, or awaiting the task rather than joining the thread. That is a judgement call, so no fix is offered, as with CC017, CC020, CC024, and CC027.

Conservative by design

  • The framework types are resolved from the compilation and matched by symbol, so a consumer's own System.Threading.Thread<T> — same name, same namespace — is not mistaken for the primitive.
  • Members are matched through their override chain, so ManualResetEvent.WaitOne resolves to WaitHandle.WaitOne.
  • A provably zero timeout is a probe, not a wait, and is excluded — including TimeSpan.Zero, default, new TimeSpan(), new TimeSpan(0), and new TimeSpan(0, 0, 0), none of which is a compiler constant.
  • Monitor.Wait is exempt from that exclusion: a zero timeout only ends the condition wait, and the call still cannot return until it reacquires the monitor, which can block behind another thread.
  • SemaphoreSlim.Wait is left to CC026, which owns it and can offer a real fix.

Also

The provably-zero-timeout check moved to CancellationTokenHelpers.HasProvablyZeroTimeout, shared by CC026 and CC031 rather than copied per rule — a copy is how one rule ends up recognising a zero form the others do not.

867 tests passing (was 850). 31 diagnostics.

1.31.0

Fix-safety release

Every rule whose code fix inserts an await now withholds that fix where the await would not compile, and reports the diagnostic without one.

CC030 shipped with this guard in v1.30.0 and CC028 had half of it. CC013, CC015, CC022, CC025, and CC026 had none — applying their fix in these positions turned compiling code into a build error.

Where the fix is withheld

Syntactic — a lock body (CS1996), an exception filter, an unsafe context (CS4004, unsafe modifier as well as block, propagating into nested functions), a query clause outside the two positions CS1995 permits.

Ref-like lifetimes (CS4007 / CS9217 / CS8178) — an await may not split the life of a ref struct. Covered:

  • a live Span<T> local, a using var ref struct (disposed at scope exit), an out Span<T> declaration expression
  • ref-struct foreach enumerators — including when the collection is an ordinary class and only GetEnumerator() returns a ref struct — and ref iteration variables, in both foreach syntax forms
  • unnamed temporaries: Consume(stackalloc int[1], task.Result), a ref-like call receiver (span.Slice(task.Result)), a ref-returning argument (Consume(ref GetRef(), …)), and custom interpolated-string handlers
  • storage locations rather than copied values: span[0] = task.Result is caught, Consume(span[0], task.Result) is not
  • control flow the syntax hides: loop headers that run after the body, backward goto, and goto case / goto default

And where it is not. Source position is not liveness, so the guard also avoids withholding valid fixes: locals already out of scope, nameof(span) references, untaken conditional arms, opposite if/else arms, sibling switch sections, values consumed before the await, and — since await using awaits at disposal — a span read before scope exit, or a ref struct declared after this one (disposal runs in reverse order).

The findings do not change

Blocking I/O inside a lock is exactly the stall these rules exist to surface. Only the automated rewrite is withheld, because resolving it means restructuring the surrounding code — the author's call, not a mechanical edit.

Design

Both halves sit behind CancellationTokenHelpers.AwaitInsertionIsUnsafe, so a future await-inserting rule gets the guard by asking one question rather than rediscovering the compiler errors one at a time.

850 tests passing (was 822). No diagnostic IDs or severities changed.

1.30.0

New rule: CC030 — blocking Process.WaitForExit() in async code

WaitForExit() is the worst-behaved member of the blocking-in-async family. The wait is unbounded and depends on a program outside your control, so a hung child process pins a thread-pool thread indefinitely — and no cancellation, shutdown signal, or request abort can reclaim it.

CC002 cannot cover this. It fires on calls that have a token-accepting overload; here the async form is a differently-named method.

// ❌ CC030
public async Task RunToolAsync(Process process)
{
    process.WaitForExit();
    await Task.Yield();
}

// ✅ fix
await process.WaitForExitAsync(cancellationToken);

Conservative by design

  • WaitForExit(int) is not flagged — it returns bool and WaitForExitAsync takes only a token, so no rewrite preserves the call's meaning.
  • Symbol-gated to System.Diagnostics.Process; quiet unless the target framework actually exposes WaitForExitAsync (.NET 5+), so .NET Framework consumers never see an impossible suggestion.
  • The rewrite is bound before it is claimed: the analyzer speculatively binds the exact call the fix will emit and stays quiet unless it resolves to the framework method, so a subclass hiding WaitForExitAsync cannot produce a broken fix.

Reported without a fix

The call is genuinely blocking, but no safe mechanical rewrite exists:

  • null-conditional calls, and invocations inside a ?. chain
  • await-forbidden contexts: lock bodies (CS1996), exception filters, unsafe contexts (CS4004, modifier as well as block), query clauses outside the two positions CS1995 permits
  • where the inserted await would span a ref-like lifetime (CS4007/CS9217): Span<T> locals live across the call, using var ref structs, ref-struct foreach enumerators (both loop forms), ref iteration variables, out Span<T> declaration expressions, and loop headers whose condition or incrementor runs after the body

Fix fidelity

Trivia survives — comments in the receiver, on the member name, and inside the argument list. Keyword parameter names are re-escaped (@​event, @​await). When the in-scope token's name is shadowed, the fix falls back to the parameterless form rather than dropping the finding.

Also

The await-forbidden-context check moved into shared helpers now that a second rule needs it, alongside new shared speculative-binding and rewrite builders — the call an analyzer checks is now literally the call its fixer writes.

822 tests passing (was 788).

1.29.0

CC028 now covers the System.IO.Stream primitives

Read, Write, CopyTo, and Flush were a silent false negative. The rule keyed on the exact declaring type name (File, StreamReader, StreamWriter), so blocking on a stream inside async code was never flagged — despite every one of those methods having a token-taking async counterpart. source.CopyTo(destination) in an async method blocks the thread for the entire transfer.

// ❌ CC028
public async Task ArchiveAsync(Stream source, Stream destination)
{
    source.CopyTo(destination);
    await Task.Yield();
}

// ✅ fix
await source.CopyToAsync(destination, cancellationToken);

Matching

  • Stream membership resolves the invoked member back to its original definition on Stream, so FileStream, NetworkStream, GZipStream, and user subclasses are covered at any depth of overriding — while a subclass's own Write(string) convenience overload is not.
  • MemoryStream is excluded (in-memory buffer; the async form only wraps the same synchronous work), including T where T : MemoryStream receivers.

Fix safety

The rule's contract is that the rewrite it offers always compiles. This release makes that hold under adversarial subclass shapes: Roslyn speculatively binds the exact call the fix would emit, and the diagnostic is only reported when it resolves to the intended counterpart. Candidates must be public, non-hiding-static, generic-inferable, and yield a substitutable awaited result.

Where the call is genuinely blocking but no safe mechanical rewrite exists, the diagnostic is reported without a fix: named arguments that would be remapped, and await-forbidden contexts (lock bodies, exception filters, unsafe contexts, and query clauses outside the two positions CS1995 permits).

Also

  • Code fix title is now "Use the async I/O method"; it carries the counterpart's own token parameter name.
  • Package release notes and README install snippets track the package version, now asserted by tests rather than hardcoded.

788 tests passing (was 753). No diagnostic IDs or severities changed.

1.28.1

Changed

Discoverability release for CancelCop.Analyzer 1.28.1:

  • Keyword-rich NuGet title, description, and tags for CancellationToken / async/await search (sync-over-async, RequestAborted, ASP.NET Core, EF Core, HttpClient, roslyn-analyzer)
  • Conversion-funnel README with product-flow visuals (IDE diagnostics, code fix, analyzer+CI loop)
  • Packs assets/ for NuGet README rendering
  • Adds DiscoverabilityMetadataTests and scripts/verify-packages.sh

Diagnostic IDs and severities are unchanged from 1.28.0 (including CC029).

Install

<PackageReference Include="CancelCop.Analyzer" Version="1.28.1">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>

https://www.nuget.org/packages/CancelCop.Analyzer/1.28.1

1.28.0

Added

  • CC029 (LinkedTimeoutTokenSourceAnalyzer): flags a timeout CancellationTokenSource (new CancellationTokenSource(TimeSpan|int) or CancelAfter on a parameterless local) when an in-scope parent token is not linked. Code fix rewrites to CreateLinkedTokenSource(token) + CancelAfter(delay).

This catches the common ASP.NET / worker bug where a timeout silently drops RequestAborted or the caller's cancellation.

Validation

  • 750 tests passed (Release, net10.0).

1.27.224

Changed

  • Reworked the GitHub and NuGet README around CancellationToken and async Roslyn search intent.
  • Replaced the stale package README that advertised 9 analyzers and 111 tests with the root README as a single source of truth.
  • Corrected build, compatibility, test-count, sample, project-layout, and default-branch guidance.
  • Expanded NuGet title, description, and tags across C#, .NET, ASP.NET Core, EF Core, HttpClient, gRPC, SignalR, MediatR, async/await, and code-fix discovery terms.

Validation

  • 733 tests passed locally and in GitHub Actions.
  • Release build, pack, package layout, README byte comparison, and consumer diagnostic smoke test passed.
  • Independent Claude review returned clean after one documentation correction.

1.27.223

Fixed

  • CC019 now classifies direct negated type-pattern rethrows by polarity and cancellation-hierarchy overlap.
  • Guards that swallow OperationCanceledException, a derived cancellation type, or a possible interface-implementing cancellation subtype are diagnosed, while disjoint and same-named custom types stay quiet.

Verification

  • 732 tests passed.
  • Release build, package inspection, and consumer smoke test passed.

1.27.222

Fixed

  • CC022 now verifies that the analyzed target framework exposes CancellationTokenSource.CancelAsync() before reporting Cancel().
  • .NET 6 and .NET 7 projects no longer receive a non-compiling migration suggestion.

Verification

  • 726 tests passed.
  • Release build, package inspection, and consumer smoke test passed.

1.27.221

Fixed

  • CC005B now analyzes MVC controller actions decorated with [AcceptVerbs(...)] and offers the existing add-token fix.
  • Same-named attributes outside Microsoft.AspNetCore.Mvc remain excluded.

Verification

  • 725 tests passed.
  • Release build, package inspection, and consumer smoke test passed.

1.27.220

CC005C: positional unreduced EndpointRouteBuilderExtensions Map calls now analyze and fix lambda and method-group handlers with exact framework and route-builder gates. Verified by 722 tests, Release build, package inspection, PR CI, and master CI.

1.27.219

CC015: statically imported Task.WaitAll and Task.WaitAny calls are now diagnosed in async code while zero-timeout, shadowing, and sync guards remain quiet. Verified by 717 tests, Release build, package inspection, PR CI, and master CI.

1.27.218

CC020/CC021: null-conditional reduced extension calls now count as context handoffs while ordinary instance calls remain diagnostic. Verified by 712 tests, Release build, package inspection, PR CI, and master CI.

1.27.217

CC020/CC021: chained null-conditional CancellationToken and RequestAborted reads now count as observation while nested-object members remain excluded. Verified by 709 tests, Release build, package inspection, PR CI, and master CI.

1.27.216

Fixed CC020/CC021 false positives: direct null-conditional context token reads now count as runtime observation, while similarly named downstream members do not.

1.27.215

Fixed a CC022 false negative: null-conditional CancellationTokenSource.Cancel() calls are now diagnosed in async code. No automatic fix is offered because preserving null semantics requires a control-flow rewrite.

1.27.214

Fixed a CC002 false negative by classifying explicit arguments by their parameter-converted type, so boxed token expressions no longer masquerade as propagation while contextual token defaults remain recognized.

1.27.213

Fixed a CC019 false negative: a conditional rethrow restricted to an unrelated exception type no longer masks cancellation swallowing, while OperationCanceledException guards remain recognized.

1.27.212

CC009 now ignores cancellation checks deferred inside nested lambdas or local functions when evaluating an enclosing loop.

1.27.211

CC016 and CC017 now diagnose cancellation-token parameters only passed as out, while ref, in, and ordinary forwarding remain observations.

1.27.210

CC012 now diagnoses and fixes CancellationToken.None imported through using static while keeping custom None properties quiet.

1.27.209

CC016 and CC017 now diagnose cancellation-token parameters that are only overwritten before use, while preserving right-hand-side reads as real observation.

1.27.208

Fixed

  • CC012 now diagnoses repeatedly parenthesized CancellationToken.None, typed default, and default-literal arguments when a token is available.
  • The code fix replaces the complete outer argument expression cleanly.

1.27.207

Fixed

  • CC014 now recognizes actual parameterless framework IDisposable.Dispose() invocations through an exact built-in interface cast.
  • Arbitrary casts, user-defined conversions, and custom Dispose extension calls remain diagnostic.

1.27.206

Fixed

  • CC027 now diagnoses tasks returned from calls on an existing local disposed by expression-form using (resource).
  • Analysis is limited to returns inside that exact using scope, preserving earlier and outside returns.

1.27.205

Fixed

  • CC014 now treats parentheses as transparent for CancellationTokenSource disposal and conservative ownership escape.
  • Mixed parenthesized/null-forgiven references retain their semantics, while non-disposal calls remain diagnostic.

1.27.204

Fixed

  • CC013 now excludes provably zero framework TimeSpan durations so scheduler-yield semantics are not rewritten to synchronously completing Task.Delay calls.
  • Runtime-determined and nonzero TimeSpan sleeps remain diagnostic.

1.27.203

Fixed

  • CC014 now treats null-forgiving operators as transparent for CancellationTokenSource disposal and conservative ownership escapes.
  • Non-disposal calls through the same syntax remain diagnostic.

1.27.202

Fixed

  • CC028 now diagnoses blocking System.IO.File calls made through using static imports.
  • The fixer rewrites them to the bare async counterpart and flows a supported in-scope cancellation token.

1.27.201

Fixed

  • CC013 no longer diagnoses the zero-millisecond scheduler-yield form Thread.Sleep(0).
  • Positive and runtime-determined sleeps in async code remain diagnosed.

1.27.200

Fixed

  • CC020 and CC021 now treat a reduced extension-method receiver as semantic context handoff.
  • Ordinary instance calls still require explicit cancellation observation and remain diagnostic.

1.27.199

Fixed

  • CC010 no longer reports a redundant missing-token diagnostic when a custom async-enumerable ConfigureAwait overload already receives a CancellationToken.
  • Boolean ConfigureAwait configuration without token flow remains diagnosed.

1.27.198

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.197...v1.27.198

1.27.197

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.196...v1.27.197

1.27.196

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.195...v1.27.196

1.27.195

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.194...v1.27.195

1.27.194

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.193...v1.27.194

1.27.193

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.192...v1.27.193

1.27.192

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.191...v1.27.192

1.27.191

CC026 now excludes exact zero-TimeSpan SemaphoreSlim.Wait probes.

1.27.190

CC015 now treats zero-timeout Task.WaitAll and Task.WaitAny calls as immediate probes.

1.27.189

CC015 now excludes exact zero-TimeSpan Task.Wait probes while preserving potentially blocking timeout diagnostics.

1.27.188

CC015 no longer diagnoses Task.Wait(0), a guaranteed immediate completion probe.

1.27.187

CC022 and CC025 now recognize async top-level programs while preserving purely synchronous top-level behavior.

1.27.186

CC024 now diagnoses async lambdas converted to custom void-returning delegates while preserving the sanctioned event-handler delegate shape.

1.27.185

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.184...v1.27.185

1.27.184

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.183...v1.27.184

1.27.183

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.182...v1.27.183

1.27.182

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.181...v1.27.182

1.27.181

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.180...v1.27.181

1.27.180

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.179...v1.27.180

1.27.179

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.178...v1.27.179

1.27.178

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.177...v1.27.178

1.27.177

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.176...v1.27.177

1.27.176

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.175...v1.27.176

1.27.175

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.174...v1.27.175

1.27.174

What's Changed

Full Changelog: georgepwall1991/CancelCop.Analyzer@v1.27.173...v1.27.174

Commits viewable in compare view.

Updated iTextSharp.LGPLv2.Core from 3.8.2 to 3.8.3.

Release notes

Sourced from iTextSharp.LGPLv2.Core's releases.

No release notes found for this version range.

Commits viewable in compare view.

Updated Microsoft.Extensions.Http.Polly from 9.0.0 to 9.0.18.

Release notes

Sourced from Microsoft.Extensions.Http.Polly's releases.

9.0.18

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.17...v9.0.18

9.0.17

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.16...v9.0.17

9.0.16

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.15...v9.0.16

9.0.15

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.14...v9.0.15

9.0.14

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.13...v9.0.14

9.0.13

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.12...v9.0.13)

9.0.12

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.11...v9.0.12

9.0.11

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.10...v9.0.11

9.0.10

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.9...v9.0.10

9.0.9

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.8...v9.0.9

9.0.7

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.6...v9.0.7

9.0.6

Bug Fixes

  • Forwarded Headers Middleware: Ignore X-Forwarded-Headers from Unknown Proxy (#​61622)
    The Forwarded Headers Middleware now ignores X-Forwarded-Headers sent from unknown proxies. This change improves security by ensuring that only trusted proxies can influence forwarded header values, preventing potential spoofing or misrouting issues.

Dependency Updates

  • Bump src/submodules/googletest from 52204f7 to 04ee1b4 (#​61762)
    Updates the GoogleTest submodule to a newer commit, bringing in the latest improvements and bug fixes from the upstream project.
  • Update dependencies from dotnet/arcade (#​61714)
    Updates internal build and infrastructure dependencies from the dotnet/arcade repository, ensuring compatibility and access to the latest build tools.
  • Update dependencies from dotnet/extensions (#​61571)
    Refreshes dependencies from the dotnet/extensions repository, incorporating the latest features and fixes from the extensions libraries.
  • Update dependencies from dotnet/extensions (#​61877)
    Further updates dependencies from dotnet/extensions, ensuring the project benefits from recent improvements and bug fixes.
  • Update dependencies from dotnet/arcade (#​61892)
    Additional updates to build and infrastructure dependencies from dotnet/arcade, maintaining up-to-date tooling and build processes.

Miscellaneous

  • Update branding to 9.0.6 (#​61831)
    Updates the project version and branding to 9.0.6, reflecting the new release and ensuring version consistency across the codebase.
  • Merging internal commits for release/9.0 (#​61925)
    Incorporates various internal commits into the release/9.0 branch, ensuring that all relevant changes are included in this release.

This summary is generated and may contain inaccuracies. For complete details, please review the linked pull requests.

Full Changelog: v9.0.5...v9.0.6

9.0.5

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.4...v9.0.5

9.0.4

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.3...v9.0.4

9.0.3

Release

What's Changed

Full Changelog: dotnet/aspnetcore@v9.0.2...v9.0.3

9.0.2

Release

What's Changed

Description has been truncated

@dependabot
Bump the tests group with 6 updates
c4dc71a 
Bumps CancelCop.Analyzer from 1.27.173 to 1.38.0
Bumps iTextSharp.LGPLv2.Core from 3.8.2 to 3.8.3
Bumps Microsoft.Extensions.Http.Polly from 9.0.0 to 9.0.18
Bumps microsoft.web.librarymanager.cli from 3.0.71 to 3.0.114
Bumps SonarAnalyzer.CSharp from 10.29.0.143774 to 10.30.0.144632
Bumps System.ServiceModel.Syndication from 9.0.0 to 9.0.18

---
updated-dependencies:
- dependency-name: CancelCop.Analyzer
  dependency-version: 1.38.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: tests
- dependency-name: iTextSharp.LGPLv2.Core
  dependency-version: 3.8.3
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: tests
- dependency-name: Microsoft.Extensions.Http.Polly
  dependency-version: 9.0.18
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: tests
- dependency-name: microsoft.web.librarymanager.cli
  dependency-version: 3.0.114
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: tests
- dependency-name: SonarAnalyzer.CSharp
  dependency-version: 10.30.0.144632
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: tests
- dependency-name: System.ServiceModel.Syndication
  dependency-version: 9.0.18
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: tests
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added .NET Pull requests that update .net code dependencies Pull requests that update a dependency file labels Jul 27, 2026
@dependabot dependabot Bot mentioned this pull request Jul 27, 2026
Closed
@dependabot @github

dependabot Bot commented on behalf of github Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #337.

@dependabot dependabot Bot closed this Jul 28, 2026
@dependabot
dependabot Bot deleted the dependabot/nuget/dot-config/tests-9f4225e6aa branch July 28, 2026 19:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .net code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants