Get ubuntu-latest green, and clear the three codegen follow-ups

[matt-edmondson]

Closes #191, #193, #194, #195 — everything left over from #182 and #187.

The four land on one branch because that's the branch this work stream uses; they're independent and reviewable in commit order.

#191 — Test on ubuntu-latest goes green

Red on main since 8b9df02 added Linux to the matrix, with 92 failures, every one in the path tests. The new coverage found what it was added to find on its first run: these tests had only ever run on Windows and had its spelling of everything baked in.

All 92 were test assumptions, not Semantics.Paths defects. The library takes its separators from System.IO.Path and treats a backslash as an ordinary filename character where that is what it is — which is correct. The tests asserted the Windows answer and got the right answer for the wrong platform. IsChildOf_WithMixedSeparators_WorksCorrectly, which the issue singled out as worth reading carefully, is one of these: it failed only because its C:\projects fixture won't construct on Linux.

TestPaths composes fixtures from Path.DirectorySeparatorChar and a platform-appropriate root, so TestPaths.Absolute("projects", "app") is C:\projects\app on Windows and /projects/app elsewhere.

Windows behaviour is unchanged by construction. Rendering every converted fixture back into its Windows spelling reproduces the original string literal exactly — I checked this mechanically across all 14 files, and the only lines that don't round-trip are the ones I deliberately restructured. Worth saying, because a green Linux run proves nothing about the platform these tests came from. CI bears it out: Test on windows-latest is green on every commit here.

Mixed-separator fixtures use Path.AltDirectorySeparatorChar rather than a hard-coded backslash. On Unix both separators are /, so those cases degrade to ordinary paths instead of smuggling in a backslash and quietly testing something else.

Eleven weren't fixture spelling and needed a decision:

Case	Decision
UNC (\\server\share)	Windows-only concept — [OSCondition(OperatingSystems.Windows)] + [TestCategory("OS-Specific")], matching the existing Parent_OfUncShareRoot_ReturnsTheShareItself
< > : | in names	Reserved on Windows, legal in a Unix filename. The validators ask the running platform via Path.GetInvalidFileNameChars, so accepting them off Windows is the correct answer, not a gap. Same gating, reason recorded on each test
"rejects path separators"	Now builds the separator from Path instead of hard-coding \, so it asserts the thing it's named for on both platforms rather than one

AbsoluteDirectoryPathParentTests was already platform-correct via a per-platform conditional; TestPaths makes one expression cover both, so the conditional goes.

#193 — SEM001 and SEM003 now say where

SEM004 got a source location in #182; these two were left at Location.None because the collectors that raise them never received the MetadataFile. dimensions.json is thousands of lines and both are typo-catchers, so "which name is wrong" without "where it is written" leaves the reader to do most of the work.

The two want different searches. SEM001 names something that exists nowhere, so the first occurrence in the file is the mistake — the existing unscoped FindLocation is right. SEM003 names dimensions that all exist and are spelled correctly; searching for one unscoped lands on its first legitimate mention somewhere else entirely. Technically a location, practically a wrong answer. So FindLocation gains a scoped overload — find the owning dimension's own "name", then the relationship's "other" at or after it — falling back to the unscoped search and then to Location.None, so an unfamiliar metadata layout degrades to today's behaviour rather than to nothing.

GeneratorDiagnosticTests gains an AssertPointsAt helper that reads the covered text back out of the metadata. That strengthens the existing SEM004 test, which moves onto it: it asserted only that the location wasn't Location.None, which would have passed for a location pointing at the wrong entry — the exact failure mode this is about.

#194 — no more RS2002

Seven warnings on every build, one per SEM diagnostic. The release-tracking analyzer only sees descriptors exposed through DiagnosticAnalyzer.SupportedDiagnostics; these are reported by source generators, which have no such property. Omit them from AnalyzerReleases.Unshipped.md and RS2008 fails the build; include them and RS2002 warns.

Identifiers stay tracked; RS2002 is silenced in Semantics.SourceGenerators.csproj with a comment saying why the rule can't be satisfied here. AnalyzerReleaseTrackingTests already enforces what RS2008 enforces from a vantage point that can see the descriptors. Verified: a clean build of the project reports 0 warnings.

#195 — the Sonar reproduction reaches all six projects

CustomBeforeMicrosoftCommonProps reaches only Semantics.SourceGenerators, the one project using the <Project Sdk="..."> attribute form. The five ktsu.Sdk projects use <Sdk Name="..." /> elements, which that hook doesn't reach. CustomAfterMicrosoftCommonProps does, and is still early enough for restore to pick up the analyzer PackageReference:

dotnet build -p:CustomAfterMicrosoftCommonProps=$PWD/.sonarlint/sonar-local.props

Verified by seeing Sonar findings reported against Semantics.Color and Semantics.Music, neither of which the Before hook reached at all. The "Known limitation" paragraph is replaced with the caveat that actually applies: the globalconfig was calibrated against this repository's profile, so a clean local run is strong evidence rather than proof.

The backlog it exposed

Triaged rather than deferred, since all three were errors under the raised severities:

• Oklab.Cbrt, S1244 — the exact-zero check is correct: the Newton-Raphson step divides by x * x, and x is zero only when value is, so a tolerance band would send small-but-valid inputs down the shortcut and lose the precision the refinement exists to recover. Suppressed at the method with that justification.
• NormalizedParameter.Logarithmic, S1244 — same shape, but here it rewrites cleanly: comparing Math.Sign results says "is zero" without comparing floats. No suppression needed.
• DimensionsGenerator, S3267 — the loop only reads dimension.Name, so it iterates the names.

One finding is mine: threading MetadataFile? through for #193 pushed ResolveForms to eight parameters (S107). The relationship, its file, its owning dimension and its field path all travel together and exist only to let a diagnostic say where it is, so they become one RelationshipSite. ResolveForms drops to four parameters and ReportFormMissing to three.

Test coverage on the new code

The first push cleared CI but failed SonarCloud's gate at 66.7% coverage on new code against a required 80%. Measuring the same thing locally — cobertura output intersected with the lines this branch adds — reproduced it at 76.5% and named the same two files. Every gap was real, so the last commit closes them with tests rather than padding:

• The eight SEM001 report sites are one per relationship kind per field, each with its own field-path message, and only integrals[...].other had a test. A rename dropping any of the other seven would have failed nothing. Now a DataRow per kind and field, asserting both the location and the field path in the message.
• SEM003 had only its self branch covered. The other two participants are the interesting ones: a cross product needs the form on its other operand and on its result, and the diagnostic has to name whichever is missing rather than the dimension that owns the relationship.
• MetadataFile.FindLocation's scoped overload had its happy path covered through SEM003 and none of its fallbacks — which are the whole reason it's safe to use. MetadataFileTests now covers both overloads directly, including a null SourceText.

SonarCloud now reports 100.0% coverage on new code, matching the local measurement of 52/52 lines exactly.

Verification

• Linux: 1127 total, 0 failed, 1119 passed, 8 skipped — the 8 being the Windows-only cases above. Test on ubuntu-latest green for the first time since the matrix added it.
• Windows: green throughout.
• Verify Generated Files: green. git diff over Semantics.Quantities/Generated/ after a rebuild is empty — nothing here changes emitted code.
• SonarCloud quality gate: passed, 100% coverage on new code, 0 security hotspots, 0% duplication.

Not verified from here: SonarCloud reports 2 new issues alongside the passing gate. sonarcloud.io is unreachable from the agent sandbox (the network policy 403s the CONNECT), so I can't enumerate them, and the local analyzer reproduction doesn't surface them — it reports only the pre-existing Semantics.Test backlog (S4144 on identical test bodies, S101 on SSNString), which this branch doesn't touch. Anyone with dashboard access can see what they are in a click; they didn't block the gate.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud