♻️ Use LSP based file watcher

[SPGoding]

Resolves #1414.

For testing purposes, the Output tab includes outputs prefixed with [FsWatcher] with the raw LSP changes, added files, changed files, and unlinked files, whenever file system changes are detected.

[SPGoding]

During testing I noticed there was a bug with VS Code's built-in file watcher:

0. Create a file at a/b/c/file.txt
1. Rename a to a2
2. Rename c to c2

Expected Results:

Raw LSP changes should include

{
  changes: [
    {
      uri: 'file:///a2/b/c2',
      type: 1
    },
    {
      uri: 'file:///a2/b/c',
      type: 3
    }
  ]
}

Actual Results:

Raw LSP changes instead include

{
  changes: [
    {
      uri: 'file:///a/b/c2',
      type: 1
    },
    {
      uri: 'file:///a/b/c',
      type: 3
    }
  ]
}

Notice that folder a2's old name a is shown in the output. The new LspFsWatcher will be unable to send correct events as the path included in LSP raw changes does not actually exist.

[misode]

During testing I noticed there was a bug with VS Code's built-in file watcher: [...]

@SPGoding During testing I could not reproduce this issue. I correctly get the addition of 'file:///a2/b/c2', and removal of 'file:///a2/b/c'. Either this is OS-dependant or I am following the steps incorrectly.

Regardless of me being able to reproduce, is this a blocking issue meaning we can't go forward with this LSP based watcher approach? Or are there workarounds to resolve this?

[misode]

In addition to solving the renaming bug on Windows, this also seems to greatly improve performance! While before it would take upwards of 60 seconds to load the Gamemode 4 repo (cached), it now only takes 16 seconds!

I experienced one issue when deleting a very large folder, with a OOM crash.

[misode]

In #1607 Afro started working on being able to exclude certain patterns from the watcher. From testing, the watcher seems to be very performant so this may not be necessary, but I did see raw LSP changes in .git/FETCH_HEAD for example. Do these have potential to break anything? If we want to do any filtering, should we do it here or later in LspFsWatcher.onLspDidChangeWatchedFiles?

[SPGoding]

[I]s this a blocking issue meaning we can't go forward with this LSP based watcher approach? Or are there workarounds to resolve this?

I don't think this is a blocking issue. I do think it'd be nice if we can fix the OOM problems first though.

[misode]

I tested this on a simple data pack and I encountered issues where symbols were not updating when I created/renamed/deleted json files. I found one part of the issue so now new json files show up as symbols.

But deleting or renaming a json file still leaves the old symbol as a definition in the symbol table. I tried doing some debugging but couldn't immediately spot the issue. SymbolUtil.removeLocationsFromSymbol seems to be correctly removing the location, but then trim thinks that the symbol is not trimmable.

[SPGoding]

Thanks for testing. I think I know what's the problem. I'll let you know after I fix it and do some more testing on my own.