fsautocomplete becomes unresponsive after running dotnet restore

[joprice]

When running neovim with ionide, if I run a command like a dotnet restore or dotnet build without --no-restore, the fsautocomplete process spikes to 5-600% cpu and becomes unresponsive. I have to force kill it to make progress. I've started running commands with --no-restore, but when I do need to restore, which is quite often when publishing and releasing private libs, I end up having a quite cumbersome workflow and my poor battery suffers. Is there some configuration that could help this or is this perhaps a known issue?

[TheAngryByrd]

I've not had this happen and I tend to do dotnet restore a lot, however I use VSCode, so maybe neovims LSP implementation is doing something odd.

Just for context, for FsAutocomplete to work properly, a dotnet restore has to happen before so the tooling can find the proper DLLs to load for typechecking. Whenever you do additional dotnet restores, if those file change (like clean then restore), it will have to go thru the process of discovering those DLLs again. If it's a rather large project, it could take time to find/load those DLLs.

[joprice]

Still haven't spotted an interesting log, but when it gets into this state, I get lots of errors like this one:

ionide: -32603: Check aborted (Aborted). Errors: [||]

Probably not helpful, a symptom of something else gone wrong.

[TheAngryByrd]

It's possible there's an issue in FSAC but from my experience, it tends to be a problem in the F# compiler itself that we've exposed thru how we use it. Definitely looking forward to the log if you get one that makes sense.

[joprice]

Yea that makes sense that it's usually project specific, but what I'm starting to notice is that once a particular file gets into the errors: [||], other files work an continue to provide up to date type information as I change and save the files, but that first file doesn't any longer. If I close vim and restart, it works. Meanwhile, dotnet build will succeed. The only logs I've been able to correlate before the issue sets in are formatting errors, so my hunch is that an some exception is thrown by the parser, and puts the file's state into something sticky that it doesn't recover from. I'll keep digging in further over the next few weeks and try to get to the bottom of it, since this isn't enough yet to narrow it down.

[joprice]

I finally saw the errors again:

internal error: Operations that change non-concurrent collections must have exclusive access. A concurrent update was perform rrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The
 ed on this collection and corrupted its state. The collection's state is no longer correct. [193]

This appears intermittently multiple times throughout the file.

In the lsp log, there are also some errors like:

internal error: One or more errors occurred. (Assembly: The system type 'System.Array' was required but no referenced system DLL contained this type, full path: System.Array

[TheAngryByrd]

internal error is a s sign it's a problem with FSharp.Compiler.Service itself so unfortunately you'll have to open an issue on https://github.com/dotnet/fsharp.

The system type 'System.Array' was required

This one tends to be because the project isn't restored.