Consume the extracted source-generator toolkit from its package

[matt-edmondson]

Closes #192. Closes #181.

What this does

CodeGen/ and the test harness moved to ktsu-dev/SourceGeneratorToolkit and ship as two packages, both published at 1.0.0:

• ktsu.SourceGeneratorToolkit
• ktsu.SourceGeneratorToolkit.Testing

This is the repoint:

• Deleted Semantics.SourceGenerators/CodeGen/ (GeneratorBase.cs, MetadataFile.cs, DiagnosticCatalog.cs, CSharpKeywords.cs) and Semantics.Test/Quantities/GeneratorHarness.cs.
• Added ktsu.SourceGeneratorToolkit to Semantics.SourceGenerators (PrivateAssets="all" GeneratePathProperty="true", so it bundles alongside the generator the way ktsu.CodeBlocker does), and both packages to Semantics.Test.
• Repointed the usings: Semantics.SourceGenerators.CodeGen → ktsu.SourceGeneratorToolkit, harness → ktsu.SourceGeneratorToolkit.Testing.
• Emit.cs now references CSharpKeywords from the package rather than through the old nested namespace.
• Updated CLAUDE.md to describe where the base classes come from now.

Semantics.SourceGenerators is now Models/, Metadata/, Generators/ and the Semantics-specific bindings — SemanticsGenerator, SemanticsDiagnostics, and the half of Emit that is about physics rather than C#. That was #181's definition of done.

One deviation from the plan recorded on #192

The issue said GeneratorHarness ships in the package. It ships, but as a second package, ktsu.SourceGeneratorToolkit.Testing, rather than inside the analyzer one.

The harness reads metadata off disk, which RS1035 bans for code that runs in an analyzer host. Putting it in the main package would have meant suppressing RS1035 project-wide there, and losing that guard for GeneratorBase and MetadataFile — which genuinely do run inside the compiler. Splitting keeps EnforceExtendedAnalyzerRules on where it matters, and a consumer testing their own generator still gets the harness, which was the point of shipping it at all.

The dependency split is as #192 specified: Roslyn and System.Collections.Immutable are PrivateAssets="all"; ktsu.CodeBlocker and System.Text.Json flow to consumers. Verified against the built .nuspec.

The seam is unchanged

SemanticsGenerator<T> and SemanticsMultiFileGenerator still bind this repository's diagnostic catalogue and file header onto the package's GeneratorBase in one place. That is what keeps the package free of anything specific to this repository, and it should stay.

Validation

Verified against the live nuget.org feed, with the locally-packed copy purged from the NuGet cache first so nothing could resolve from it:

• Full solution builds clean.
• 1127 tests pass, 0 failures, 8 skipped (Windows-only).
• Generated output under Semantics.Quantities/Generated/ is byte-identical — confirmed green by Verify Generated Files in CI, and the alias props need no regeneration.
• Sonar analyzers (.sonarlint/sonar-local.props) report 5 findings, all pre-existing in files this change does not touch (TextValidationAttributesTests.cs, Paths/DirectoryNameTests.cs).

Earlier CI failures on this head (resolved)

The first runs failed with NU1101 on both toolkit packages — they had not published yet, so nothing compiled. That is fixed; the re-runs restore from nuget.org normally. No code on this branch changed between those failures and the re-runs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJU8zt8qf83C9mznh5ZhRd

---

Generated by Claude Code

[matt-edmondson]

CI is red on the expected blocker, not on this change

Two checks failed on d1cdded — Test on ubuntu-latest and Generated files up to date — both with the same restore error:

error NU1101: Unable to find package ktsu.SourceGeneratorToolkit.
  No packages exist with this id in source(s): nuget.org
error NU1101: Unable to find package ktsu.SourceGeneratorToolkit.Testing.
  No packages exist with this id in source(s): nuget.org

Nothing compiled, so neither check reached the code this PR changes. Generated files up to date fails for the same reason — it rebuilds before it diffs.

Why it isn't this PR's to fix. The packages don't exist on nuget.org yet. The pipeline that publishes them is still running on ktsu-dev/SourceGeneratorToolkit@main. There is no fix to port into this branch: the fix is the package being published. This is the same sequencing #187 had while waiting on ktsu.CodeBlocker 1.3.0.

The change itself is validated. Built and tested locally against the packed 1.0.0 through a temporary local NuGet source: full solution builds, 1127 tests pass with 0 failures, and generated output under Semantics.Quantities/Generated/ is byte-identical — so Generated files up to date will pass once restore succeeds.

Not re-running yet. A re-run now would fail identically. I'm holding it until the package publishes, then re-running and correcting the pinned version here if the release pipeline computes something other than 1.0.0.

One thing I can't do myself: if NUGET_KEY / KTSU_PACKAGE_KEY aren't available to the new repository, publishing will stall and this stays blocked until those secrets are added.

I'm watching this PR and will drive it to green once the package is up.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[matt-edmondson]

Green — the blocker above is resolved

Both packages published at 1.0.0 (ktsu.SourceGeneratorToolkit, ktsu.SourceGeneratorToolkit.Testing), and the re-runs on this same head (d1cdded) are all green:

Check	Result
.NET Workflow (Linux + Windows)	✅ success
Verify Generated Files	✅ success — generated output byte-identical
SonarCloud quality gate	✅ passed — 0 new issues, 0 security hotspots
Code scanning	✅ success

mergeable_state: clean. No code changed between the red runs and these — only the packages appearing on nuget.org.

Ready to merge. Merging closes #192 and #181, which completes the epic.

---

Generated by Claude Code