Greptile Summary

This PR propagates the Roslyn quirk fix from #6473 — where unmanaged also sets HasValueTypeConstraint, making the generated struct, unmanaged pair a CS0449 error — to all remaining source generators that emit generic type constraints. Six sites across five generators are patched; MockImplBuilder (explicit-interface-impl semantics) and TestMetadataGenerator (constraint checking, not emission) are intentionally left unchanged.

• CS0449 fix (CollectionShapeAssertionGenerator): guards struct with !HasUnmanagedTypeConstraint and reorders unmanaged before notnull, matching canonical C# constraint order.
• Silent-downgrade fix (PropertyInjectionSourceGenerator): reorders an else-if chain so HasUnmanagedTypeConstraint is tested before HasValueTypeConstraint, making the unmanaged branch reachable.
• Never-emitted unmanaged fix (AssertionExtensionGenerator ×2, AssertionMethodGenerator, MethodAssertionGenerator, ShouldExtensionGenerator): adds an explicit unmanaged block alongside the guarded struct block; backed by four new TFM-matrix snapshot tests for MethodAssertionGenerator.

Confidence Score: 4/5

Safe to merge — all constraint-emission sites that were producing invalid or silently-downgraded constraints are now corrected, and the intentionally-untouched sites (MockImplBuilder explicit-impl, TestMetadataGenerator checking) are well-reasoned.

The logic changes are straightforward and self-consistent across all six patched sites. The only gap is that new snapshot tests were added only for MethodAssertionGenerator; the five other fixed generators have no new test coverage for the unmanaged path, so a future regression in those generators would not be caught automatically.

The generator files themselves look correct; tests/TUnit.Assertions.SourceGenerator.Tests/MethodAssertionGeneratorTests.cs is the only new test file and covers just one of the six fixed sites.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ITypeParameterSymbol] --> B{HasReferenceTypeConstraint?}
    B -- Yes --> C[emit class]
    B -- No --> D{HasValueTypeConstraint AND NOT HasUnmanagedTypeConstraint?}
    D -- Yes --> E[emit struct]
    D -- No --> F{HasUnmanagedTypeConstraint?}
    F -- Yes --> G[emit unmanaged]
    F -- No --> H{HasNotNullConstraint?}
    H -- Yes --> I[emit notnull]
    H -- No --> J[no primary constraint]
    C --> K[emit ConstraintTypes loop]
    E --> K
    G --> K
    I --> K
    J --> K
    K --> L{HasConstructorConstraint?}
    L -- Yes --> M[emit new constraint]
    L -- No --> N[done]
    M --> N

_{Reviews (1): Last reviewed commit: "fix: apply 'unmanaged' constraint handli..." | Re-trigger Greptile}

Code review

Reviewed the diff (5 source generators + PropertyInjectionSourceGenerator, plus the new MethodWithUnmanagedConstraint snapshot test).

Correctness: Traced through each of the six changed sites against Roslyn's HasUnmanagedTypeConstraint/HasValueTypeConstraint co-setting quirk:

• The four independent-if sites (ShouldExtensionGenerator, AssertionExtensionGenerator ×2, AssertionMethodGenerator, MethodAssertionGenerator) correctly guard struct emission with && !HasUnmanagedTypeConstraint and add unmanaged separately.
• CollectionShapeAssertionGenerator's reordering (unmanaged before notnull) is consistent with the others and still precedes the ConstraintTypes loop.
• PropertyInjectionSourceGenerator's else if chain now checks HasUnmanagedTypeConstraint before HasValueTypeConstraint, fixing the previously-unreachable unmanaged branch — matches the pattern already fixed in [TUnit.Mocks] Generated mock for interface with 'unmanaged' type constraint does not compile (emits 'where T : struct, unmanaged') #6471.
• No site produces an invalid combination (e.g. unmanaged, notnull) — the special-constraint flags are mutually exclusive on any single Roslyn type parameter, and the new snapshot output (where T : unmanaged, all 4 TFMs identical) confirms this empirically.

CLAUDE.md compliance: PropertyInjectionSourceGenerator.GetTypeParameterConstraints is only referenced within this one source-gen file — there's no reflection-mode (TUnit.Engine) counterpart that builds constraint clause strings, so the dual-mode rule doesn't apply to this change (constraint-clause emission is inherently a source-gen-only concern, unlike metadata collection).

Scope note (non-blocking): Only AssertionMethodGenerator got a new dedicated snapshot test; the other four sites rely on "no existing snapshot changed" as evidence. That's reasonable given the change is a narrow, mechanically-identical guard applied consistently, and the PR description is explicit that the broader dedup refactor is intentionally out of scope.

No issues found.