What's wrong
MetadataFile.FindLocation(string needle) and FindLocation(string anchor, string needle) (SourceGeneratorToolkit/MetadataFile.cs ~lines 50–91) find both the anchor and the needle with a plain ordinal Text.IndexOf. That matches inside longer names and inside JSON keys, not only whole JSON string values.
The anchored overload is documented as the fix for "a name that is spelled correctly in dozens of places and only wrong in one of them — anchoring on the surrounding entry picks the right one." Substring matching defeats that whenever one entry name is contained in another.
Repro (verified by running in a scratch copy of current main)
Metadata text, one entry per line:
{"units":[
{"name":"SquareMeter","base":"Second"},
{"name":"Meter","base":"Second"}
]}
FindLocation("Meter", "Second") returns line 2, the SquareMeter entry. The intended entry is line 3.FindLocation("Meter") also returns line 2, at a column inside SquareMeter.
Why it matters
PascalCase compound names such as SquareMeter/Meter and KiloGram/Gram are normal in the metadata this package serves (e.g. Semantics' unit/quantity metadata). A diagnostic that links to the wrong entry sends the user to the wrong line, which is worse than no location.
Suggested fix
Search for whole JSON string tokens first. Look for " + anchor + " and " + needle + ", then offset the returned span by one so it still covers only the name. Fall back to the current raw substring search only when the quoted search finds nothing, so non-string needles such as numbers still work.
Acceptance criteria
- In the repro,
FindLocation("Meter", "Second") points at line 3 and FindLocation("Meter") at the Meter value on line 3.
- A test where a longer name containing the anchor appears before the intended entry.
What's wrong
MetadataFile.FindLocation(string needle)andFindLocation(string anchor, string needle)(SourceGeneratorToolkit/MetadataFile.cs~lines 50–91) find both the anchor and the needle with a plain ordinalText.IndexOf. That matches inside longer names and inside JSON keys, not only whole JSON string values.The anchored overload is documented as the fix for "a name that is spelled correctly in dozens of places and only wrong in one of them — anchoring on the surrounding entry picks the right one." Substring matching defeats that whenever one entry name is contained in another.
Repro (verified by running in a scratch copy of current main)
Metadata text, one entry per line:
{"units":[ {"name":"SquareMeter","base":"Second"}, {"name":"Meter","base":"Second"} ]}FindLocation("Meter", "Second")returns line 2, theSquareMeterentry. The intended entry is line 3.FindLocation("Meter")also returns line 2, at a column insideSquareMeter.Why it matters
PascalCase compound names such as
SquareMeter/MeterandKiloGram/Gramare normal in the metadata this package serves (e.g. Semantics' unit/quantity metadata). A diagnostic that links to the wrong entry sends the user to the wrong line, which is worse than no location.Suggested fix
Search for whole JSON string tokens first. Look for
"+ anchor +"and"+ needle +", then offset the returned span by one so it still covers only the name. Fall back to the current raw substring search only when the quoted search finds nothing, so non-string needles such as numbers still work.Acceptance criteria
FindLocation("Meter", "Second")points at line 3 andFindLocation("Meter")at theMetervalue on line 3.