[thomhurst]

Summary

Assertion types declared in the global namespace (no namespace declaration) made the assertion source generators emit using <global namespace>;, which broke the consumer's build with errors pointing into generated files (CS8955, CS8802).

Root cause

The generators recorded the declaring type's namespace with INamespaceSymbol.ToDisplayString(). For the global namespace that returns the literal text <global namespace>. The emitter writes using {namespace}; whenever that string is non-empty.

The issue names AssertionMethodGenerator ([AssertionFrom]) and MethodAssertionGenerator ([GenerateAssertion]). AssertionExtensionGenerator ([AssertionExtension]) had the same bug, and I reproduced it with the same test.

Fix

In all three generators, the model stores null when ContainingNamespace.IsGlobalNamespace is true, so the existing IsNullOrEmpty check skips the using. The global namespace needs no using. ContainingTypeData.ContainingNamespace in MethodAssertionGenerator is now string?.

Tests

• tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespaceRegressionTests.cs: one test per generator. Each runs the generator on a global-namespace input and compiles the input together with the generated output. It requires that the output does not contain <global namespace> and that the compilation has zero errors. Snapshots are accepted for all four TFMs. All three tests failed before the fix.
• tests/TUnit.Assertions.Tests/Bugs/Tests7133.cs: an end-to-end check. Global-namespace [AssertionFrom], [GenerateAssertion] and [AssertionExtension] declarations compile in a real project and work at runtime, both pass and fail cases.

Test runs:

• TUnit.Assertions.SourceGenerator.Tests, full suite: net10.0, net9.0 and net8.0 pass 73/73. On net472, 71/72 pass. The one failure is MethodAssertionGeneratorTests.ParamsParameter (CS0234 UnconditionalSuppressMessageAttribute). It existed before this change and is unrelated: that input is not in the global namespace. I filed it separately.
• TUnit.Assertions.Tests with --treenode-filter "/*/*/Issue7133GlobalNamespaceTests/*" on net10.0: 4/4 pass.

Fixes #7133

Summary by CodeRabbit

• Bug Fixes

  • Assertion generators now correctly handle assertions declared in the global namespace, allowing generated assertions and extensions to compile and work as expected.

• Tests

  • Added coverage for global-namespace assertions across supported target frameworks.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-19T21:14:15.526389Z	44da632	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 12ae7c34-6e0b-40d3-b27f-5cd4e3467170

📥 Commits

Reviewing files that changed from the base of the PR and between 44da632 and a1dcbd7.

📒 Files selected for processing: 11

• src/TUnit.Assertions.SourceGenerator/Generators/AssertionExtensionGenerator.cs
• src/TUnit.Assertions.SourceGenerator/Generators/AssertionMethodGenerator.cs
• src/TUnit.Assertions.SourceGenerator/Generators/CollectionShapeAssertionGenerator.cs
• src/TUnit.Assertions.SourceGenerator/Generators/MethodAssertionGenerator.cs
• src/TUnit.Assertions.SourceGenerator/Generators/NamespaceHelper.cs
• tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespaceCollectionShapeAssertionTests.CollectionShapeWrapper_InGlobalNamespace_EmitsValidTypeName.DotNet10_0.verified.txt
• tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespaceCollectionShapeAssertionTests.CollectionShapeWrapper_InGlobalNamespace_EmitsValidTypeName.DotNet8_0.verified.txt
• tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespaceCollectionShapeAssertionTests.CollectionShapeWrapper_InGlobalNamespace_EmitsValidTypeName.DotNet9_0.verified.txt
• tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespaceCollectionShapeAssertionTests.CollectionShapeWrapper_InGlobalNamespace_EmitsValidTypeName.Net4_7.verified.txt
• tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespaceRegressionTests.cs
• tests/TUnit.Assertions.SourceGenerator.Tests/TestData/GlobalNamespaceCollectionShapeAssertionSource.cs

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 4 remain after this review.

📝 Walkthrough

The assertion generators now represent global namespaces as null rather than "<global namespace>". Regression tests cover generated output, compilation, collection-shape generation, and use of global-namespace assertions.

Changes: Global Namespace Assertions

Layer / File(s)	Summary
Global namespace modeling src/TUnit.Assertions.SourceGenerator/Generators/NamespaceHelper.cs, src/TUnit.Assertions.SourceGenerator/Generators/AssertionExtensionGenerator.cs, src/TUnit.Assertions.SourceGenerator/Generators/AssertionMethodGenerator.cs, src/TUnit.Assertions.SourceGenerator/Generators/MethodAssertionGenerator.cs, src/TUnit.Assertions.SourceGenerator/Generators/CollectionShapeAssertionGenerator.cs	The generators store null for global namespaces and retain displayed names for named namespaces. ContainingNamespace is nullable. Collection-shape generation omits the namespace segment for global-namespace targets.
Generated output and compilation coverage tests/TUnit.Assertions.SourceGenerator.Tests/TestData/GlobalNamespace*, tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespaceRegressionTests.cs, tests/TUnit.Assertions.SourceGenerator.Tests/GlobalNamespace*verified.txt	Global-namespace test inputs cover assertion-from, generated-method, assertion-extension, and collection-shape generation. Regression tests check generated output and compilation. Verified snapshots contain generated assertion output across supported target frameworks.
Assertion usage regression tests/TUnit.Assertions.Tests/Bugs/Tests7133.cs	Tests invoke the three global-namespace assertion forms. A test checks that the generated positive assertion throws AssertionException for -1.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~12 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to a1dcb

Global-namespace assertions and collection wrappers avoid invalid namespace qualifiers, while named-namespace output retains its namespace. No actionable merge-blocking risk is evident.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 4.35% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 23 functions across 11 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly describes the main change: preventing invalid using directives for assertion types declared in the global namespace.
Linked Issues check		Issue #7133 requires usable global-namespace assertions for [AssertionFrom] and [GenerateAssertion]. The three assertion generators now use NamespaceHelper.GetNamespaceOrNull, which omits the gl…
Out of Scope Changes check		The changes remain connected to issue #7133. The AssertionExtensionGenerator and CollectionShapeAssertionGenerator changes fix the same global-namespace handling defect. The helper, snapshots, tes…

Full details: Linked Issues check

Explanation

Issue #7133 requires usable global-namespace assertions for [AssertionFrom] and [GenerateAssertion]. The three assertion generators now use NamespaceHelper.GetNamespaceOrNull, which omits the global namespace from generated using directives. The collection-shape generator also emits valid global::X names. Regression tests compile global-namespace input for all affected generators and cover runtime use. The reported focused tests pass.

Full details: Out of Scope Changes check

Explanation

The changes remain connected to issue #7133. The AssertionExtensionGenerator and CollectionShapeAssertionGenerator changes fix the same global-namespace handling defect. The helper, snapshots, test inputs, compile checks, and end-to-end tests support and verify that fix. No unrelated product behavior is identified.

• Fix all pre-merge checks with AI

✨ Finishing Touches: 💡 1

📝 Generate docstrings: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit checks the namespace line,
No global label slips inside.
New assertions compile and run,
With empty strings and tests begun.
I nibble, hop, and mark the fix!}

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Review

The fix is correct and minimal. All three generators (AssertionExtensionGenerator, AssertionMethodGenerator, MethodAssertionGenerator) now store null for the global namespace. The existing IsNullOrEmpty guards then skip the using. Changing ContainingTypeData.ContainingNamespace to string? is consistent with that. I read GenerateAssertions in MethodAssertionGenerator and checked its using emission against the new null; it handles it. The snapshot tests for all three generators and the end-to-end Tests7133 runtime test cover the regression well.

Suggestions, none of them blocking:

• The same expression, ContainingNamespace is { IsGlobalNamespace: false } ns ? ns.ToDisplayString() : null, is now repeated in three places. A small shared helper such as GetUsingNamespaceOrNull(INamespaceSymbol) would keep the next generator from reintroducing this bug.
• CollectionShapeAssertionGenerator.cs:88 builds global::{target.ContainingNamespace.ToDisplayString()}.{target.Name}. It would produce global::<global namespace>.X for a global-namespace wrapper. That is likely rare, because the attribute is internal to TUnit. It is still worth confirming, or applying the same helper.

Approve.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable defects were found.

Summary

Fixes generated assertion code for types declared without a namespace.

• Global-namespace assertions now generate usable assertion methods.
• Collection-shape wrappers now name global types correctly.

No actionable issues were found in the changes since the previous review. Tests were not run during this review.

_{Reviews (2) · Last reviewed commit: "refactor(assertions): share global-names..." · Reviewed by Greptile}

[thomhurst]

Review dispositions:

• github-actions: the global-namespace check appears in three places; extract a shared helper. Fixed in a1dcbd7. NamespaceHelper.GetNamespaceOrNull(INamespaceSymbol?) now handles this check in AssertionExtensionGenerator, AssertionMethodGenerator, MethodAssertionGenerator and CollectionShapeAssertionGenerator.
• github-actions: CollectionShapeAssertionGenerator.cs:88 builds global::<global namespace>.X. I confirmed it, and it is fixed in a1dcbd7. A global-namespace wrapper now gets global::X. The new snapshot test GlobalNamespaceCollectionShapeAssertionTests covers it on all four TFMs. I checked that the test fails when the old line is put back. The attribute is internal, so users are unlikely to hit this today.
• macOS modularpipeline failure. This PR did not cause it. ExecutionTimeTests.Completes_Within_Unhappy/Unhappy2 measured 1.19s and 1.32s against a fixed 1s wall-clock bound on the arm64 runner. Tracked in Flaky: ExecutionTimeTests.Completes_Within_Unhappy* exceed 1s wall-clock bound on macOS CI #7159.

[github-actions]

Review

The fix is correct and small. NamespaceHelper.GetNamespaceOrNull is applied at all three using-emitting sites (AssertionMethodGenerator, MethodAssertionGenerator, AssertionExtensionGenerator). It also covers the global::<global namespace>.X bug in CollectionShapeAssertionGenerator. The ContainingTypeData.ContainingNamespace type change to string? fits the existing IsNullOrEmpty check. The tests compile the generator output and also include a runtime end-to-end test. I didn't build or run anything.

I checked the remaining ContainingNamespace.ToDisplayString() call sites in the base checkout. They are comparisons against fixed namespace strings, so <global namespace> can't cause a bug there. One thing to confirm: MethodAssertionGenerator.cs:596 reads containingType.ContainingNamespace as originalNamespace. I haven't traced how it's used, so check it handles the global namespace.

Suggestion (optional): the ToDisplayString() mistake is easy to repeat, so a small Roslyn analyzer or a lint test that flags raw ContainingNamespace.ToDisplayString() in the generators could prevent a repeat. The helper plus the regression tests are probably enough.

Approve from my side.

[thomhurst]

Review dispositions for a1dcbd7. There are no code changes in this round.

CI (.NET run 39337252693). The run did not fail; GitHub cancelled every job about a minute in, before any step ran. The job annotation says: "Canceling since a higher priority waiting request for .NET-fix/issue-7133-global-namespace-using exists". That comes from the workflow's cancel-in-progress concurrency group, and no newer .NET run for this branch exists, so nothing replaced it. Locale, CloudShop, smoke and Claude review passed on the same commit. I reran the cancelled jobs (attempt 2).

github-actions review (22:53):

• Check that MethodAssertionGenerator.cs:596 (originalNamespace) handles the global namespace. It already does. originalNamespace is ContainingTypeData.ContainingNamespace, which line 358 sets through NamespaceHelper.GetNamespaceOrNull(...). For a global-namespace type that is null, and line 609 (!string.IsNullOrEmpty(originalNamespace)) then skips the using. The MethodAssertionGenerator global-namespace snapshot test covers this path.
• Optional analyzer or lint for raw ContainingNamespace.ToDisplayString(). No change. The remaining raw calls are comparisons against fixed namespace strings, which the reviewer also noted are safe. With the shared helper and the regression tests on all four generators, a dedicated lint does not seem worth the extra machinery.