The panel guessed that any capitalised identifier was a type, so
`Profiler.Frames.Count` came out as three type-coloured names where the
editor shows a class and two members. The semantic overlay already fetches
per-file tokens, so feed the same data to the webview.
- codeSpans() returns the server's token spans per referenced line in the
row's own trimmed coordinates; rows carry them and the webview colours from
them, mapping token type names to its palette. Fields, properties, events
and methods share the member colour, as they do in the stock themes.
- The regex tokenizer stays as the fallback for servers that serve no
semantic tokens, and coloredReferences.semanticTokens now gates both views
rather than just the editor.
Colours are still the approximated Dark+/Light+ palette — a webview is not
given the theme's token colours — so only the editor view can be theme-exact.
The README says so instead of promising this would fix it.
Two things the new tests establish, both assumptions the code was already
making: all files in a result share the origin's legend, so decoding tokens
from every file against one legend is sound; and all 237 relocated tokens in
the Profiler search report the same type name as their source token.
Also relaxes an over-specific assertion: DotRush calls Profiler.Frames a
field, not a property. Either way it is a member, which is what matters.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
maxandClaude Opus 5
3e8ece8ed7
