x/tools/gopls: gopls.add_dependency command relies on side effects rather than sending workspace edits #44035
Labels
FrozenDueToAge
gopls
Issues related to the Go language server, gopls.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Started with:
i.e. the requirement on
golang.org/x/tools/imports
is missing fromgo.{mod,sum}
.Loading
main.go
in Vim (usinggovim
) gives error diagnostics as expected:If we ask for suggested fixes at
main.go:6
we get a code action response with thegopls.add_dependency
command.If we execute the
gopls.add_dependency
command,go.{mod,sum}
change beneath the editor andgopls
.Log files:
I haven't kept up to speed with all the conversations on this topic (and might well have forgotten key conversations, for which I apologise), but this is surprising. My expectation was that, because
tempModfile=true
, the required changes togo.{mod,sum}
would be sent as edits to those files, rather thancmd/go
being executed andgopls
relying on the editor to "see" those changes and relay them.Relying on side effects in this way is problematic:
go.{mod,sum}
open, then it should not send any changes togopls
until that buffer (to use Vim terminology) has been updated by reloading from disk. Vim at least does not automatically reload a buffer where the underlying file on disk has changed: it would be incredibly bad UX to do this by default in any case, not to mention problematic if the user has pending changesThis issue is related to #44008 in that it had been my assumption to this point that changes to
go.{mod,sum}
files were being sent as workspace edits. Hence, offering a mode of automatically adding module requirements in response an unimported completion would be trivial. If, however, our analysis is correct and instead we are relying on side effects of commands then I can see how we were very likely talking past each other.That said, I think we should be moving to a model where
gopls
sends all edits to the editor, regardless of whether a file is open or not, rather than relying on side effects, file watching etc.@stamblerre @heschik would very much welcome your thoughts.
FYI @leitzler
The text was updated successfully, but these errors were encountered: