Couple of semantic token issues

[thetarnav]

Few noticed semantic token issues to correct

generic_proc :: proc ($FOO: int) {
    //                  ⤷ `FOO` has no token

    FOO // `FOO` has a `@lsp.type.typeParameter.odin`
        // even though it's not a type
        // probably it's hardcoded for `$T: typeid` case
}

Foo :: struct {
	callback: proc ()
}
foo: Foo
foo.callback()
//     ⤷ `callback` is @lsp.type.property.odin
//        while it should probably be @lsp.type.function.odin

[BradLewis]

The second one is deliberate, even though the type of the property is a function, it is a property first so it should stay like that. I'll take a look at the first issue.

[thetarnav]

property + function = @lsp.type.method :)

I brought it up because that's how it works in other languages so I'm used to always knowing what is a function from the highlight alone.
You can even see the static highlighting on github colors it as a function.
When lsp sets a property token it overwrites the function token from treesitter/textmate.

[BradLewis]

If you have any documentation that states this shouldn't be a property I can change it, but from what I can see looking online these are correctly labeled as a property. It matches the way we treat all fields on a struct. If we were to go down this path, then should all properties instead be there respective type? (eg struct). What about proc parameters to functions, such as bar in

foo :: proc(bar: proc() -> int) {...}

[thetarnav]

I don't know of any documentation for semantic tokens. It's just a lsp spec to see what's possible and other languages for reference. The spec says nothing here and from my experience "function" takes priority over "variable", "param", "property" etc.
Otherwise why are functions highlighted at all and type.variable isn't a token for everything?
imo params should have a function token as well if they are functions. foo: proc () would be a function no matter where it's defined.
Currently it's a bit inconsistent either way:

foo := proc (      // foo - type.function
	bar: proc (),  // bar - type.parameter
) {
	bar()          // bar - type.function
	baz := bar     // baz - type.function, bar - type.function
	baz()          // baz - type.function
	qux: proc ()   // qux - type.function
	obj: struct {cb: proc ()} // cb - type.property
	obj.cb()       // cb - type.property
	ocb := obj.cb  // ocb - type.function, cb - type.property
	ocb()          // obb - type.function
}

If we were to go down this path, then should all properties instead be there respective type? (eg struct).

You mean other tokens like type.enum, type.type, type.struct?
Personally I don't care about these as I make no distinctions in highlighting enums, structs or other types.
$T: typeid will be type.typeParameter, a cross between type.type and type.parameter and that's enough.
$T: typeid/struct {...} could technically be type.struct but that's so rare it doesn't matter.

[BradLewis]

By documentation something like other lsp behaviour is also what I was after. I had a look at other LSPs and the concensus seems to be to treat these as properties.

Eg in rust https://rust-analyzer.github.io/book/features.html#semantic-syntax-highlighting

function Emitted for free-standing functions.
property Emitted for struct and union fields.

With clangd

We should definitely clean the inconsistency you've highlighted here though, I just don't think we should be changing it from being a property.