Make configuration more reliable right after starting VSCode

[hunger]

We got reports that you need to tweak the configuration for it to become applied right after starting VSCode. This effects mostly the library_path and Include_path options that need to get applied to the code when building in LS or live-preview.

I ran into several issues:

• The content cache was not initialized yet when the LSP sent the configuration
• The LSP did not invalidate any files on configuration changes, so it never noticed that the include/library paths were changed (and thus did not send the new files on to the live preview.
• The live preview raced against itself trying to render with the updated configuration but the old data. I added an explicit "commit configuration" step now to avoid that.

This greatly improves the reliability of configuration with the live preview and LS for me on first start of VSCode or when switching between WASM and binary preview.

Note: The WASM preview does not work with library_path at all for me: The compiler uses file existence tests, which always fail in WASM AFAICT.

[ogoffart]

Thanks for fixing the issue.

I don't quite understand what is the race. Could you elaborate with an example.
Maybe the config can be set directly on the cache by locking the CACHE mutex instead of message passing?

Note: The WASM preview does not work with library_path at all for me: The compiler uses file existence tests, which always fail in WASM AFAICT.

Indeed. That's another bug that can be fixed later.

[hunger]

I don't quite understand what is the race. Could you elaborate with an example.
Maybe the config can be set directly on the cache by locking the CACHE mutex instead of message passing?

It needs to go through message passing for the WASM preview to work :-/

Remember: The LS does file system accesses, the live-preview just knows the files the LS tells it about to make working with WASM-mode bearable.

So what used to happen is this:

1. LS sends "configuration changed" with a new library path.
   1.1 The live-preview sees it and re-renders with the set of sources the LS has told it about earlier
   1.1.1 The compiler checks for the library using a Path::exists. That works in binary mode, so it
   decides "@library_name is a library".
   1.1.2 It then tries to read the library. That fails as the live-preview still only knows about the old set of files
   1.1.3 It falls back further to ./@library_name, which fails, too.
   1.2 The DocumentCache records this fact and the dependency on ./@library_name.
2. The LS discovers the file @library_name points to now and tells the live-preview
   2.1 The live-preview see no reason to update: Nothing depends on this file.
3. The LS is done with its work at some point, but does not notify the live-preview about it

Tada! We are stuck in a broken state.

What happens now is this:

1. LS sends "configuration changed" with a new library path.
   1.1 the live-preview stores the new configuration and blocks the rendering
2. The LS discovers new files and tells the live-preview about it
   2.1 the live-preview records those new files but does nothing
3. the LS notifies the live-preview that it is done
   3.1 the live-preview triggers a fresh rendering
   3.1.1 The compiler checks for the library using a Path::exists. That works in binary mode, so it
   decides "@library_name is a library".
   3.1.2 It then tries to read the library. That works now!
   3.2 The DocumentCache notes the dependency on the right library file.

Tada, it works.

[ogoffart]

2.1 The live-preview see no reason to update: Nothing depends on this file.

This is the same logic with the set content. If you just set the state to NeedsReload it will reload the preview.

We can talk about that over a call on Monday.