fix(sourcegen): merge generic parameter lists in [AssertionExtension] emit

[JohnVerheij]

Description

AssertionExtensionGenerator emitted the covariant receiver-type parameter (when applied) and the assertion class's own generic parameter as two adjacent angle-bracket blocks in the generated extension method signature, for example Matches<TActual><T>(this IAssertionSource<TActual> source, ...). That's not valid C#; the generated file fails to parse for any [AssertionExtension]-decorated class that derives from Assertion<ConcreteNonSealedType> while also declaring its own generic type parameter.

Fix: collect both the covariant receiver parameter and the class's own generic parameters into a single list and emit one <...> block before the method signature opens.

Test coverage:

• New ConcreteReceiverWithExtraGenericAssertion test fixture in TestData/. Uses System.Exception as the receiver. Exception is a BCL non-sealed class that the generator's existing covariance-candidate check recognises, so the fixture trips the affected branch without adding a stand-in type to the test surface.
• New ConcreteReceiverWithExtraGeneric test on AssertionExtensionGeneratorTests. Pins the absence of adjacent generic-parameter blocks (DoesNotContain "><") and runs an inline Roslyn compile-clean gate so the whole class of emit-syntax bugs is pinned regardless of which specific diagnostic id the parser produces.

Related Issue

Fixes #5918

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Performance improvement
• Refactoring (no functional changes)

Checklist

Required

• I have read the Contributing Guidelines
• If this is a new feature, I started a discussion first and received agreement
• My code follows the project's code style (modern C# syntax, proper naming conventions)
• I have written tests that prove my fix is effective or my feature works

TUnit-Specific Requirements

• Dual-Mode Implementation: If this change affects test discovery/execution, I have implemented it in BOTH:
  • Source Generator path (TUnit.Core.SourceGenerator)
  • Reflection path (TUnit.Engine)
• Snapshot Tests: If I changed source generator output or public APIs:
  • I ran TUnit.Core.SourceGenerator.Tests and/or TUnit.PublicAPI tests
  • I reviewed the .received.txt files and accepted them as .verified.txt
  • I committed the updated .verified.txt files
• Performance: If this change affects hot paths (test discovery, execution, assertions):
  • I minimized allocations and avoided LINQ in hot paths
  • I cached reflection results where appropriate
• AOT Compatibility: If this change uses reflection:
  • I added appropriate [DynamicallyAccessedMembers] annotations
  • I verified the change works with dotnet publish -p:PublishAot=true

Testing

• All existing tests pass (dotnet test)
• I have added tests that cover my changes
• I have tested both source-generated and reflection modes (if applicable)

Additional Notes

• Dual-Mode rule is not applicable. Per .claude/docs/mandatory-rules.md Rule 1, dual-mode does not apply to assertion library changes. This PR fixes an emit defect in TUnit.Assertions.SourceGenerator only.
• Performance / AOT rules are not applicable. Small string-builder change in the emit; no allocation or reflection concern.
• Call-site ergonomics for this shape (callers having to repeat TActual at every site) is a separate design call. It's tracked as a follow-up issue rather than expanded here.
• net472 CS0122 conditional in the inline compile-clean check: on the net472 leg of CI, the test project's Polyfill assembly marks CallerArgumentExpressionAttribute as internal, producing a CS0122 ('inaccessible due to its protection level') false positive when Roslyn compiles the generator's output through the test reference set. Conditional #if NETFRAMEWORK filter pre-empts this. On modern TFMs the BCL attribute is public, so CS0122 (if it ever appears) remains a real failure signal. All four TFMs (net472 + net8.0 + net9.0 + net10.0) verified green locally before push.
• Inline compile-clean check is intentional given parallel filing. A sibling PR (Bug 1, titled "fix(sourcegen): emit default literal for value-type assertion parameters") introduces a shared CompileChecker.AssertNoErrors test helper. Both PRs were authored in parallel, so the helper isn't on main yet, and the inline form here matches the helper's body. Can rebase this branch and replace the inline copy with the shared helper once Bug 1 merges, whichever order you prefer to land them in.
• Multi-target snapshots added for net8.0, net9.0, net10.0, net472.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code Review

The fix is correct and the approach is sound. This is a clean, minimal change that directly addresses the root cause.

What the fix does

AssertionExtensionGenerator previously emitted two separate angle-bracket blocks when a class had both a covariant receiver type parameter (TActual) and its own generic parameters (T), producing invalid C# like Method<TActual><T>(...). The fix collects all generic parameters into a single List<string> and emits one merged <TActual, T> block. All four edge cases are handled correctly:

genericTypeParam	genericParams	Before	After
TActual	[T]	<TActual><T> ❌	<TActual, T> ✅
TActual	[]	<TActual> ✅	<TActual> ✅
null	[T]	<T> ✅	<T> ✅
null	[]	`` ✅	`` ✅

The genericParamsString variable is still correctly used for the return type (assertionType.Name + genericParamsString), so that path is unaffected.

Minor observations

DoesNotContain("><") assertion — this catches the bug, but the check is slightly broader than needed and could theoretically be confused by other generated content. The positive assertion (that the snapshot contains ConcreteReceiverWithExtraGenericMatches<TActual, T>() would be a more precise regression guard. That said, the snapshot file itself already pins the exact merged signature, so the compile gate + snapshot together are the real guarantees here; DoesNotContain("><") is a belt-and-suspenders check. No action required.

Comment verbosity — the inline comments in the generator and test are more detailed than this project typically uses (CLAUDE.md: "Only add one when the WHY is non-obvious"). The WHY is actually non-obvious here (a subtle codegen bug), so some comment is warranted — but the multi-paragraph blocks could be trimmed in a future pass. Not a blocker.

#if NETFRAMEWORK CS0122 filter — well-documented workaround; acceptable.

Summary

The fix is minimal, correct, and well-tested. The snapshot files across all four TFMs confirm the output is identical and valid. Approving.

[thomhurst]

Thanks!