Change `Sequence[CompletionItemKind]` to `Sequence[CompletionItemKind | int]`?
alcarney opened this issue · comments
In situations where an enum is "open" (such as here), would it be possible to update the generator to output the union of the enum and the value type it is based on?
I'm assuming (but have not checked! 😅) that this will prevent the converter we get from lsprotocol from rejecting values it does not recognise, but are permitted by the spec.
Additional context: openlawlibrary/pygls#438
This is actually a spec bug. In the model it is marked as optional but not as supporting custom values:
This is the definition for CompletionItemKind: https://github.com/microsoft/vscode-languageserver-node/blob/691fd5d3fabeed5ed8ff9c3608f2d306cb07717e/protocol/metaModel.json#L14201-L14310
This is CodeActionKind for example with the field supportsCustomValues : https://github.com/microsoft/vscode-languageserver-node/blob/691fd5d3fabeed5ed8ff9c3608f2d306cb07717e/protocol/metaModel.json#L14460
This should be fixed upstream first.
I can add a custom exception for this to be explicitly treated as supports custom values.
Since we can work around it I don't think there's a big rush to fix this - especially since I assume any fix would go into 2024.x anyway? If it's better to fix it in the spec first then I'm happy to go with that.
Is it enough to open a PR against the meta model and set supportsCustomValues to true, or are there more steps involved?
The meta-model is built from TS object definitions. The change would have to be reflected where the TS object for CompletionItemKind is done. You might want to follow how this is done for ErrorCodes.
I assume any fix would go into 2024.x anyway?
We could backport the fix if it has high impact on older versions. But this seems like one of those cases that can go into 2024.x.