-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: filter noisy code actions when triggerKind is automatic #65167
Comments
The behavior is non-deterministic. Sometimes for the same request (case 1 Light bulb on editor), gopls returns the quickfix for printf analyzer. During the same session (without editing...):
vs
|
It looks like gopls doesn't return 'inline' when the request specifies "only":["quickfix"]. So it looks like the behavior is in fact deterministic. Is the bug that VS Code should specify "quickfix"? Or should gopls not return inline when the action is automatic. |
Per discussion: the problem is simply that "inline" is often not useful, and so therefore should be filtered when the triggerKind is automatic. |
We should do this filtering for [email protected], since the inline lightbulb is distracting. @adonovan do you want to do this, since you're currently working in the codeaction codebase? |
Sure, I can take this. Selecting a statement triggers the "extract" lightbulb. Should it be treated similarly? Should all of these actions appear only on the Refactor menu (no lightbulb)? |
I'll defer to @hyangah for what the VS Code UI should do, but it seems reasonable that if the region is a single point and trigger is automatic, there is no user intent. |
Change https://go.dev/cl/556555 mentions this issue: |
Make several mechanical clean-ups to analyzer implementations, reducing the complexity of their configuration and normalizing behavior. - Remove the "type error" analyzer category, since it is now an unused distinction. - Make "stubmethods" an ordinary analyzer, since it no longer needs special logic in the code action handler. - Revert infertypeargs to be an ordinary analyzer (golang/go#63821), but make its severity "hint", so that it doesn't show up in the problems tab. - Remove the "convenience" analyzer category, which only existed for the enabled/disabled configuration. The only effect of this is that the "fillstruct" analyzer can no longer be disabled, but since code actions should not be disruptive (golang/go#65167), it should be OK to have them all available. Notably, we don't allow disabling other code actions. Fixes golang/go#63821 Fixes golang/go#61559 Change-Id: I2a1cd01ea331c26fdbb35d6b5c97562c2a1f9240 Reviewed-on: https://go-review.googlesource.com/c/tools/+/556555 Reviewed-by: Alan Donovan <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Robert Findley <[email protected]>
I don't think this is going to make the v0.15.0 release. It's OK to move it to v0.16.0. |
Change https://go.dev/cl/587555 mentions this issue: |
Change https://go.dev/cl/590935 mentions this issue: |
CL 587555 suppressed some code actions if the request was triggered automatically, but that was too invasive and suppressed useful code actions like quick fixes and organize imports. Maybe some refactoring code actions and source.* actions can be also useful enough to be presented in the light bulb menu. Partially revert CL 587555, by suppress only refactor.inline code action if the user's intention is not refactoring (e.g. cursor move around a function call). However, if the user selected a code area (function name), that is likely an action for refactoring, so continue to present refactor.inline in the light bulb menu. Fixes golang/go#67823 Fixes golang/go#65167 Change-Id: I2d4a3d92199e501103596d0aed78ece34760149f Reviewed-on: https://go-review.googlesource.com/c/tools/+/590935 Auto-Submit: Hyang-Ah Hana Kim <[email protected]> Reviewed-by: Robert Findley <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
gopls version: built @ c467be3
What did I do?
Triggered printf diagnostics and SA1006 diagnostics
Settings:
What did you expect
Gopls detects the issue and provides quick fixes for these diagnostics.
What did you see instead
Gopls detected the issues, but code actions are not available from the editor (neither with the light bulb nor the Quick Fix hover)
Light bulb on editor and Hover on editor - don't work.
Light bulb on PROBLEMS panel - sort of worked
Traces
It looks like VS Code triggers code actions in different ways.
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeAction
VS Code sent a request asking for quick fixes for detected problems. (See "context" filled with the diagnostic&its source, and
triggerKind:2
(TriggerKind: "Automatic"). Gopls returned "inline call to Fprintln" code action, which doesn't make sense.Note that VS Code asked quick fixes for "printf" analyzer, but not for SA1006 analyzer's report. This can be a client-side issue and I will investigate it separately.
VS Code sent the request asking for quick fixes for detected problems. (See "context" filled with the diagnostic&its source, and
triggerKind:1
(TriggerKind "Invoked"). Gopls returned nothing.VS Code sent request with "quickfix" and "triggerKind: 1". Gopls returned some code actions for SA1006 diagnostic (but with duplications)
But didn't return codeactions for printf diagnostic.
The text was updated successfully, but these errors were encountered: