Stream: t-compiler/wg-rls-2.0

Topic: token options


Jeremy Kolb (Feb 14 2020 at 21:20, on Zulip):

@matklad do you think it's reasonable if WorldState::options holds a Vec of lsp_types::SemanticTokenTypes and modifiers? In other words do we care if it knows about lsp types directly or should I store them as strings instead?

Jeremy Kolb (Feb 14 2020 at 21:21, on Zulip):

at some point we need the server to compare its list of supported token types/modifiers with the clients and use that as the list to generate tokens and modifiers from

matklad (Feb 14 2020 at 21:22, on Zulip):

I would probably put that info in conv.rs

matklad (Feb 14 2020 at 21:23, on Zulip):

I think we need

fn token_legend() -> LspLegend

and just the usual ConvWith impl? Ie, we don't need to hold any state apparently?

Jeremy Kolb (Feb 14 2020 at 21:25, on Zulip):

Well... I think you need to loop through the server tokens and compare them with what the client supports and use that as the legend to send back from the server capabilities: https://github.com/microsoft/vscode-languageserver-node/blob/master/testbed/server/src/server.ts#L111

matklad (Feb 14 2020 at 21:27, on Zulip):

Hm, I would think this is advisory? Like, the server could adapt its tokens to the client ones, but it doesn't have to?

Jeremy Kolb (Feb 14 2020 at 21:33, on Zulip):

That's not how I'm reading the code but I do see in the comments that describe the encoding that "at index 5*i+3 - tokenType: will be looked up in SemanticTokensLegend.tokenTypes" so maybe you are right. It would certainly make it easier and I wouldn't have to deal with client caps

Jeremy Kolb (Feb 14 2020 at 21:33, on Zulip):

I'll go with that

Last update: Jun 07 2020 at 10:00UTC