Add capability information to the metamodel

[MariaSolOs]

Closes microsoft/language-server-protocol#2059.

[MariaSolOs]

@dbaeumer The spec doesn't mention a server capability for the workspace/configuration request so I'm unsure about this. Since this is requested by the server it seems like there's no server capability needed here?

[MariaSolOs]

@dbaeumer Do you think we should add capability information for requests like callHierarchy/incomingCalls that don't define their own capabilities and instead depend on whether the server supports other methods (in this case textDocument/prepareCallHierarchy)?

[MariaSolOs]

@microsoft-github-policy-service agree

[dbaeumer]

@MariaSolOs just a heads up. We have house keeping month in Dezember. New features have to wait until next year.

[MariaSolOs]

@MariaSolOs just a heads up. We have house keeping month in Dezember. New features have to wait until next year.

Thanks for the heads-up. Although this isn't user facing so I wouldn't consider it a new feature per se, I understand. I'll wait until January then!

[MariaSolOs]

@dbaeumer happy new year!

Are you available to take a look at this PR? :)

[dbaeumer]

Yes. Will look into it this week.

[dbaeumer]

The change looks good to me. The only thing I am wondering is that we have a lot of repetition and if we want to change something we need to use find / replace. Alternatively we could investigate something like this:

Current

export const capabilities: { client: 'textDocument.selectionRange'; server: 'selectionRangeProvider' } = { client: 'textDocument.selectionRange', server: 'selectionRangeProvider' }

New

type CM<C extends string, S extends string> = { client: C; server: S };
namespace CM {
   export function create<C extends string, S extends string>(client: C, server: S): CM<C, S> {
       return { client, server };
   }
}

export const capabilities: CM<'textDocument.selectionRange', 'selectionRangeProvider'> = CM.create('textDocument.selectionRange', 'selectionRangeProvider');

Then if we every want to change something we can either do that inside the type definition / or function or at least can use find all references to see where it is used.

What do you think?

[MariaSolOs]

The change looks good to me. The only thing I am wondering is that we have a lot of repetition and if we want to change something we need to use find / replace. Alternatively we could investigate something like this:

Current

export const capabilities: { client: 'textDocument.selectionRange'; server: 'selectionRangeProvider' } = { client: 'textDocument.selectionRange', server: 'selectionRangeProvider' }

New

type CM<C extends string, S extends string> = { client: C; server: S };
namespace CM {
   export function create<C extends string, S extends string>(client: C, server: S): CM<C, S> {
       return { client, server };
   }
}

export const capabilities: CM<'textDocument.selectionRange', 'selectionRangeProvider'> = CM.create('textDocument.selectionRange', 'selectionRangeProvider');

Then if we every want to change something we can either do that inside the type definition / or function or at least can use find all references to see where it is used.

What do you think?

That sounds like a good idea. I'll update the PR.

[MariaSolOs]

Hmm @dbaeumer how do you want this solution to handle the cases were only a single capability has been documented? Take the workspace/configuration request as an example: There's only the client capability (workspace.configuration)

[dbaeumer]

We could define the type parameters as C extends string | undefined and then use undefined to indicate there is no server or client capability. But I have not tested it if it works :-)

[MariaSolOs]

We could define the type parameters as C extends string | undefined and then use undefined to indicate there is no server or client capability. But I have not tested it if it works :-)

Yeah the thing is that if we do that I think we would lose the literal typing. But I'll play with it.

[MariaSolOs]

@dbaeumer I just tried your suggested approach of using CM.create to generate these capability objects, but then this complicates the generator script because the initializer node here is now a call expression (and I don't even think we could invoke it to get the output object literal).

[dbaeumer]

You don't need to invoke the call expression. You need to look at the arguments of the call expression and then take the arguments and use them in the meta model.

[MariaSolOs]

You don't need to invoke the call expression. You need to look at the arguments of the call expression and then take the arguments and use them in the meta model.

Thank you for the hint. I've updated the code to follow your suggested approach :)