Expose base type of enumeration

[rchl]

Enumerations that specify supportsCustomValues now get the base type (str or int) included where those are referenced.

It solves the use case that #37 was solving but in a different way.

Note that root_symbol_name was unused.

[rchl]

From the spec perspective it is probably correct because the value is a bitwise flag so not necessarily the exact value that matches one of the enums.

[jwortmann]

I've probably should have written this before approving/merge, but didn't pay close attention to this comment.

Actually the type of a bitwise combination of IntFlag members is also considered to by that IntFlag. So unless WatchKind also supports custom values, this UInt is probably not needed.

[rchl]

It doesn't work to directly assign a number (even if its the value of one of the IntFlag's):

But of course it works to combine enum flags so in theory we could do without int... It would have to be then special-cased in generator.

[jwortmann]

That's true, but I would say that is a good thing, because we should only use predefined values or combinations of the predefined values from the WatchKind IntFlag in the code.

[jwortmann]

There are only two types from the LSP specs that use IntFlag in the generated types: WatchKind and ApplyKind.

lsp-python-types/lsprotocol/lsp.json

Lines 15438 to 15462 in 8c62a64

	{
	"name": "WatchKind",
	"type": {
	"kind": "base",
	"name": "uinteger"
	},
	"values": [
	{
	"name": "Create",
	"value": 1,
	"documentation": "Interested in create events."
	},
	{
	"name": "Change",
	"value": 2,
	"documentation": "Interested in change events"
	},
	{
	"name": "Delete",
	"value": 4,
	"documentation": "Interested in delete events"
	}
	],
	"supportsCustomValues": true
	},

lsp-python-types/lsprotocol/lsp.json

Lines 15539 to 15559 in 8c62a64

	{
	"name": "ApplyKind",
	"type": {
	"kind": "base",
	"name": "uinteger"
	},
	"values": [
	{
	"name": "Replace",
	"value": 1,
	"documentation": "The value from the individual item (if provided and not `null`) will be\nused instead of the default."
	},
	{
	"name": "Merge",
	"value": 2,
	"documentation": "The value from the item will be merged with the default.\n\nThe specific rules for mergeing values are defined against each field\nthat supports merging."
	}
	],
	"documentation": "Defines how values from a set of defaults and an individual item will be\nmerged.\n\n@since 3.18.0",
	"since": "3.18.0"
	},

But it seems that ApplyKind is not actually used as a bitwise flag, so that could be a bug in the generator? It also does not have supportsCustomValues set in the metaModel.

I would say the generator should not produce the union type for IntFlag, even if supportsCustomValues is set.

[rchl]

Follow-up in #40

[rchl]

But it seems that ApplyKind is not actually used as a bitwise flag, so that could be a bug in the generator?

Not sure what would you consider a bug. That we don't create an union or that we use IntEnum for it?

It also does not have supportsCustomValues set in the metaModel.

We only create union when supportsCustomValues is true.

[jwortmann]

No, the bug is that we don't use IntEnum for it.

Currently it is IntFlag, but that is wrong:
https://github.com/sublimelsp/LSP/blob/50fa4b40a970e7e8e6f62520aba66c47bf4bb7fb/protocol/__init__.py#L733

It should be IntEnum instead.

[rchl]

We had an override for it - addressed in #40
Also tested that LSP code base has no type issues with that change.