General language service flakiness

[minestarks]

UPDATE 12pm:

Narrowed down to commit 8be9143 .

Minimal repro for completion issue:

1. Build python .\build.py --wasm --npm --vscode --play --no-check --no-test to build VS Code extension
2. F5 to launch with the "Run VS Code Web Extension" configuration
3. Open a .qs file from the samples directory and start typing in it.

Expected:
Completion list shows up

Actual:
No completion. ctrl+space does force completion list to show up.

No qsharp.json involved anywhere.

This looks suspect in the debug output:

ERR recursive use of an object detected which would lead to unsafe aliasing in rust: Error: recursive use of an object detected which would lead to unsafe aliasing in rust
  at imports.wbg.__wbindgen_throw (file:///Users/swernli/Programming/qsharp/vscode/out/extension.js#vscode-extension:31495:11)
  at wasm://wasm/008e4686:wasm-function[2298]:0x1c2b3d
  at wasm://wasm/008e4686:wasm-function[2300]:0x1c2b59
  at wasm://wasm/008e4686:wasm-function[1667]:0x1af2a7
  at _LanguageService.get_completions (file:///Users/swernli/Programming/qsharp/vscode/out/extension.js#vscode-extension:31061:22)
  at QSharpLanguageService.getCompletions (file:///Users/swernli/Programming/qsharp/vscode/out/extension.js#vscode-extension:32000:41)
  at async QSharpCompletionItemProvider.provideCompletionItems (file:///Users/swernli/Programming/qsharp/vscode/out/extension.js#vscode-extension:32980:25)
  at async Se.provideCompletionItems (../../../vs/workbench/api/worker/extensionHostWorker.js:98:52770)

---

ORIGINAL:

There are many repros, but this is the one I'm working off. Will update the issue when I find a minimal repro and a specific blame commit.

1. Build locally from ad2bfab
2. Build from main, f5 to launch VS Code test instance
3. Create a folder named test in the root of the workspace (which is samples)
4. Create a file named foo.qs inside test.
5. Define an operation with @EntryPoint in that file. Observe language service behavior. errors, completions seem to work
6. Save the file.
7. Create test/qsharp.json with contents {}.
8. Create another Q# file (unsaved), start typing. Observe language service beheavior. No errors.
9. Save the file as bar.qs. Observe language service behavior. errors start appearing

Second repro - single files

1. After doing the above, delete qsharp.json, delete the whole test folder, quit VSCode.
2. Restart the VS Code test instance.
3. Create a folder named test in the same place.
4. Start creating Q# files within that folder. Observe language service beheavior. no completions

[minestarks]

Change was reverted in #901 .

I believe there are roughly two root causes that's causing the flaky behavior.

1. Completions- With update_document now being async and somewhat long-running, now, the compilation is not ready by the time get_completions is called for the same keystroke that updated the document. In fact, the language service is still mutably borrowed by the time we call get_completions . The code generated by wasm-bindgen actually detects this and throws up the error above. FIX: The language service needs to be able to handle async, long-running compilation updates. This is nontrivial and requires implementing some kind of message queue for when the update messages (i.e. keystrokes) inevitably get backed up behind recompiling the project. Fix almost complete here: https://github.com/microsoft/qsharp/tree/minestarks/fix-async
2. Open buffer updates in project mode - When an open document is part of a project, and we receive buffer updates to that open document, the compilation needs to be updated with the current contents of the open buffer. Instead we reread the contents from disk for that file. The result is that it appears that updates don't even "take" until the document is saved, i.e. squiggles only appear after the document is saved. FIX: The project compilation/recompilation path needs to be reworked to take open buffers into account.

Since the issue is mitigated in main by reverting the PR, I'm closing this issue. To bring back multi-file support for the language service I believe we need to fix the two above issues first.