x/tools/gopls: prefix SignatureHelp label with "func"

[skewb1k]

Not an issue, but feature request.
Currently, SignatureHelp returns a label that is not valid Go code, which makes it difficult to parse and highlight it for clients. Many language servers work-around this by prefixing output with function declaration keyword, even though it might be redundant in the context of SignatureHelp. Unfortunately, this seems to be the only way to give the client enough context to parse the signature correctly. So there's a tradeoff here.

I've tried this and here’s a screenshots of Neovim:

Interestingly, this already happens naturally for anonymous functions, since we use "func" as their name. So the change wouldn't affect those:

One more, perhaps not very important, point is that it makes SignatureHelp match Hover look, which makes it easier to align with expectations for how function information is displayed.

I'm asking for feedback on the proposal and would be happy to submit the change - I already have a POC version ready.

[gabyhelp]

Related Issues

• x/tools/gopls: get signature when cursor is over the function name #68922 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[findleyr]

I'm not sure about this. My LSP client (coc.nvim) doesn't behave this way, even for function literals, and I like it because it aligns the signature help with the text that I'm typing:

(In this case errorf is a local function literal)

I'm assuming clients have to parse the label in order to highlight the active parameter. Since all clients seem to do this reasonably well now, do we think this change could break them?

[skewb1k]

@findleyr Sorry, I think you misunderstood the proposal. This isn't about activeParameter highlighting - it's about the syntax highlighting of the function signature itself.

The issue is that the server currently returns a snippet that isn't valid Go code. As a result, clients have to rely on their parser's ability to recover the syntax. While most can handle built-in types and keywords (like "string", "any"), they often struggle with more complex signatures - especially distinguishing argument names from types - because they lack the context that this is an argument list. That leads to unstable or inconsistent highlighting.

Even between our two setups, you can see in the screenshots that the output differs. Prefixing the label with func makes the snippet valid Go code. This allows even simple clients, or those with a minimal Go parser and no sophisticated error recovery, to apply correct syntax highlighting.

As for alignment with activeParameter - that continues to work as expected. Clients rely on activeParameter and cursor positions, not the start of the label, so adding "func " just introduces 5 extra characters to the left of popup.

[findleyr]

@skewb1k I don't think I misunderstood, I was noting that clients must already be parsing it correctly because they have to in order to highlight the active parameter. As a result, I'm wondering if changing our output would break them. Additionally, I don't actually want to see "func" in my screenshot, because that would mean the signature is misaligned with my input.

The change makes sense in theory, but the LSP is underspecified and we've been doing it this way for 5 years, and so I'm worried about chesterton's fence. Absent more understanding of why things are the way they are, I'm hesitant to endorse a change based on a principle in isolation.

How does your POC look in VS Code?