x/tools/gopls: watch file changes on disk

[ianthehat]

We cache a lot of information like the AST and typechecking data per file.
If someone changes a file outside the editor, often by doing things with their vcs (update/branch switch is the most common thing mentioned) we currently do not attempt to re-build that information unless it is invalidated by an editor change.
We should be using the LSP handling for workspace/didChangeWatchedFiles to watch all the files we are caching and invalidating them.
It is not clear if we can/should do anything if the client does not support this capability.

[myitcv]

Does this not contradict what you said the other day in terms of this being the editor's responsibility?

[ianthehat]

No, workspace/didChangeWatchedFile, s is the mechanism by which the server can ask the client to tell it when a file changes, which makes it the editors responsibility

[myitcv]

Got you. I misconstrued the title of the issue: it's actually that gopls watches these files through the client. Thanks

[myitcv]

Just jotting down a couple of notes/questions:

• This presumably includes watching the main module go.mod file itself too? i.e. it covers the situation where the user adds/drops/changes a requirement
• Will the server ask the client to watch files in the read-only module cache?
• Will the server ask the client to watch files in directory-replace-d modules which are writable? Hopefully yes 😉. Main use case here being gohack esque workflows

[ianthehat]

• Watching go.mod - yes
• Watching module cache - undecided, not doing so is more complicated, and possibly fragile, it would have to demonstrate a significant benefit, and we would have to decide if it caused issues when people clear the cache
• Watching replaced files- yes