SyntaxHighlightingToken raw value differ from specification values
krzyzanowskim opened this issue · comments
The change #758 added actor case modified SyntaxHighlightingToken.Kind indices, that now differ from the predefined values from specification https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#semanticTokenTypes. Specifically rawValue (Int32) changed for types below actor case. That may result in bogus decoding of tokens on the client side.
I think actor should be added with some value that does not collide with predefined values.
Tracked in Apple’s issue tracker as rdar://120133613
Are you actually seeing an issue somewhere? IIUC clients should be using the SemanticTokensLegend sent from the server to decode the indices.
Probably wouldn't hurt to move it to the end as with identifier though, or just remove it and have eg. parseKindAndModifiers return .class in the actor case.
Are you actually seeing an issue somewhere?
I do, because I did ignore tokens legend in my client. There's more to it. The change I proposed in #1012 cover it all.
The base list is part of the specification and its place would be in the LanguageServerProtocol module. Such model can be used as a dependency for the LSP client (I outlined the context in Propose decoupling LanguageServerProtocol from SwiftPM dependency). In that context the list is useful since client also can send a list of supported tokens (which I think is ignored by the sourcekit-lsp). Server can still extend the base list with whatever tokens it support (as I did in the PR)
The base list is part of the specification
The base kinds are part of the specification, but unless I'm misunderstanding, there's no guarantee of their order. I'm open to providing the predefined kinds in the LSP module, but IMO it's a bug in the client if it's assuming the indices returned from the server map to the order in the predefined kinds.
but IMO it's a bug in the client
it is