Semantic colors don't match other languages

[georgewfraser]

Semantic coloring is a huge improvement over the built-in textmate colors, especially for a tricky-to-color language like rust. But, the colors that are applied by rust-analyzer seem to contradict the color theme. Here is VSCode syntax coloring with semantic coloring off:

Here it is with semantic coloring on:

We can see a couple of issues. First, all keywords are purple. This contradicts other VSCode languages, like typescript, where only some keywords (for example if) are purple, and most keywords are blue. Type names, which are all green in other languages, are inconsistent: struct names are blue (the color of keywords in other languages) but enum names are green (as expected).

I'd be happy to work on changing the implementation to better match the coloring of other languages, but first I'd like to understand if this is intended behavior.

[matklad]

For keywords, see microsoft/vscode#94367. For enums and structs, we emit specific tags for types: enum for enum, struct for struct, etc. It's up to the color theme to color or not color them.

Other language "work" because they rely on regex-based based textmate scopes much more than rust.

Closing, as I belive this should be fixed in the color theme and not on our side.

[matklad]

Though, re-reading 94367, it seems like we can do better for keywords: #4353

[georgewfraser]

Help me understand---is it your view that, in the default Dark+ color theme, coloring struct type names like keywords is correct behavior? Or that it's a bug on the VSCode side? Or something else?

[georgewfraser]

This contradicts the behavior of, for example, the C++ extension, which colors struct type names like other type names:

[matklad]

This contradicts the behavior of, for example, the C++ extension

What semantic token type does C++ give for structs?

I believe we correctly flag it as struct and declaration:

[georgewfraser]

The VSCode C++ extension implemented "enhanced colorization" before VSCode defined a colorization API. It bypasses the colorization API and directly colors the tokens. So, it doesn't specify a semantic token type. However, it colors struct names the same as other type names:

Having dug into this more, it's clear to me that this is a mistake in VSCode's default mappings for semantic tokens: microsoft/vscode#97162

If they don't fix it, the solution is to simply define a rust-specific mapping from the semantic token type struct to the textmate scope entity.name.type.struct. The default mapping they currently have in place, storage.type.struct, is clearly intended for the struct keyword, not struct type names: https://macromates.com/manual/en/language_grammars

[matklad]

Oh, thanks for digging this up, fascinating find! I guess, we can paper over this by overriding the name on our side, let me cook up a PR... done, #4365.

[georgewfraser]

Syntax coloring is a small obsession of mine 😄 There are a couple other optimizations that could be done to improve client-side performance and user-experience of semantic coloring. I'm working on a PR.

[georgewfraser]

Here it is: #4383