x/tools/gopls: Add a source code action to regenerate cgo definitions.

[firelizzard18]

Is your feature request related to a problem? Please describe.
I'm always annoyed when I'm writing Go that calls C and I have to scroll up to the top of the file to click regenerate cgo definitions whenever I use a C definition I haven't used previously.

Describe the solution you'd like
When I type C.FooBar and FooBar is not yet defined I'd like a quick action to appear so I can use [Ctrl]+. to easily regenerate cgo definitions.

Describe alternatives you've considered
Adding a command to execute regenerate cgo definitions so I can bind that to a key sequence, but that command doesn't exist AFAIK.

Additional context

[h9jiang]

This gopls.regenerate_cgo is exposed from gopls. Is you request to have a wrapper command over the gopls.regenerate_cgo?

Because I think it would be best if the command have the exact same behavior as gopls.regenerate_cgo code lenses. We can figure out the argument required to run gopls.regenerate_cgo then have the wrapper command call gopls to regenerate cgo.

[firelizzard18]

That would work for me, though my ideal solution is a quick action (the lightbulb)

[firelizzard18]

The correct name for quick action is quick pick or code action, which I believe could be provided directly from gopls.

[findleyr]

So the request here is to add a code action over any undefined C symbol, to regenerate cgo definitions.

I'm not sure. Usually, the semantics for quick fixes is that they should have an (almost) guaranteed fix. In this case, the fix depends on C definitions.

We could add a source action; since source actions are meant to apply to the current file, that would make sense. WDYT?

[findleyr]

CC @adonovan

I don't think a quick fix is approprate, but either a wrapper command or source action would be reasonable.
My preference is a source action, since it benefits all editors. @firelizzard18 if you agree, we'll move this to the gopls repo and mark it help-wanted, as it should be a relatively trivial fix.

[firelizzard18]

My preference is a source action, since it benefits all editors.

That's fine with me, I added a keybind for the source action command so that will solve my problem (being able to regenerate definitions easily).

For my edification, what's the difference between source actions and code actions? Obviously vscode uses a different UI for them but if I were adding functionality to gopls it's not clear to me which I should use. Is the difference simply whether the action is attached to a specific line of code or symbol?

[adonovan]

what's the difference between source actions and code actions? Obviously vscode uses a different UI for them but if I were adding functionality to gopls it's not clear to me which I should use. Is the difference simply whether the action is attached to a specific line of code or symbol?

A Code Action is the umbrella term for "a thing you can do to a selected piece of text"; the CodeAction request returns the set of available actions. According to the protocol spec, the source.* kinds are for actions that "apply to the entire file", though gopls disregards that: we use them for anything that's not a refactoring. Some language servers seem to interpret source actions as "typing assistance", such as inserting new skeletal declarations (loops, methods, etc) into the code. Perhaps the only thing we can really say about them with any confidence is "they appear in the Source Action... menu in VS Code".