x/tools/gopls: watch file changes on disk

Question

x/tools/gopls: watch file changes on disk

ianthehat opened this issue 7 years ago · 26 comments

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.

Answer 1 · 2019-04-18T19:16:31.000Z

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

Answer 2 · 2019-04-18T19:31:07.000Z

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

Answer 3 · 2019-04-18T19:54:34.000Z

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

Answer 4 · 2019-04-29T14:53:54.000Z

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

Answer 5 · 2019-04-29T14:57:28.000Z

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

Answer 6 · 2019-07-03T17:56:36.000Z

To update this thread, I am planning to begin work on implementing workspace/didChangeWatchedFile in gopls

Answer 7 · 2019-07-10T21:05:13.000Z

Is this one available or does @suzmue still have dibs?

Answer 8 · 2019-07-11T04:28:06.000Z

I'm sorry, I mistakenly added the Suggested label here. I believe @suzmue is still working on this.

Answer 9 · 2019-07-12T22:41:15.000Z

@muirrn if you want to get started on this, I am not going to get to it right away

Answer 10 · 2019-07-14T03:50:43.000Z

Ok, I am working on this one.

Answer 11 · 2019-07-14T04:07:21.000Z

Change https://golang.org/cl/186097 mentions this issue: internal/lsp: fix watched file protocol constants

Answer 12 · 2019-08-19T17:17:53.000Z

Change https://golang.org/cl/190857 mentions this issue: internal/lsp: start handling watched file change events

Answer 13 · 2019-08-27T16:17:47.000Z

As discussed on the golang-tools call. If we are counting on the clients sending the workspace/didChangeWatchedFile event we need to make sure that the major clients actually handle this well.

There have been extensively documented and long-running issues in VSCode with file-watching. These are not Go-specific but rather with the editor itself. Despite an "experimental" new file-watcher being implemented this is still something that hasn't been addressed. Regardless of the non-Go-specificity this has notable knock-on effects on Go projects part of larger code-bases where gopls would be relying on the editor to keep track of changed files.

One entry-point to the nebula of GH issues related to this is microsoft/vscode#59679.

Answer 14 · 2019-09-04T15:17:09.000Z

Change https://golang.org/cl/193121 mentions this issue: internal/lsp: start handling watched file deletes

Answer 15 · 2019-09-16T04:36:32.000Z

Change https://golang.org/cl/195537 mentions this issue: internal/lsp: start handling watched file creates

Answer 16 · 2019-10-18T17:27:53.000Z

A reminder for an optimization that needs to be added: We should cache a mapping of directories to file URIs to speed up file creation.

Answer 17 · 2020-01-08T12:37:26.000Z

@stamblerre what's the latest status on file watching support in gopls?

I'm wondering if we can remove the workarounds we have in govim.

Thanks

Answer 18 · 2020-01-08T19:01:57.000Z

It should be coming soon, but not in time for the next gopls release. I've been doing a bit of refactoring to get it to fit in with the rest of the codebase, but the work for this is not yet complete. I will update here when it is.

Answer 19 · 2020-01-08T19:05:06.000Z

Not sure if it was intentional, but the options refactoring ended up enabling file watching be default in gopls.

Answer 20 · 2020-01-08T19:07:12.000Z

Yes, that actually was (I know it doesn't make much sense since it doesn't work yet). I just want to eliminate that option altogether, since I think it will become very difficult to investigate issues if we have multiple modes of updating files. I'm aiming to get the final few CLs out in the coming days.

Answer 21 · 2020-01-10T05:09:13.000Z

Change https://golang.org/cl/214277 mentions this issue: internal/lsp: fix support for watching changed files

Answer 22 · 2020-01-16T05:44:32.000Z

File watching now works with gopls at master. The remaining task here is to implement batching at the snapshot level, so that a single snapshot can be invalidated by multiple files instead of a single file.

Answer 23 · 2020-01-23T00:57:59.000Z

Change https://golang.org/cl/215902 mentions this issue: internal/lsp: refactor (*snapshot).clone to handle multiple URIs

Answer 24 · 2020-01-23T02:03:35.000Z

Change https://golang.org/cl/215906 mentions this issue: internal/lsp: support multiple URIs in (*view).invalidateContent

Answer 25 · 2020-01-23T02:36:16.000Z

Change https://golang.org/cl/215907 mentions this issue: internal/lsp: support batched on-disk changes in source.DidModifyFiles

Answer 26 · 2020-01-23T20:40:00.000Z

Change https://golang.org/cl/215908 mentions this issue: internal/lsp: batch file changes in didChangeWatchedFiles