Error codes persist and intellisense stops working, when editing code

[halcwb]

Describe the bug

When editing code in a medium to large project, very often, errors while typing pop up but persist and intellisense stops working.

This makes coding F# in VSCode unworkable. After each small code edit I have to recompile and close and open VScode again to see if the code is correct. Just unworkable.

Steps to reproduce

This happens so often that most users have to experience this. But I think it's related to medium to large projects.

Screenshots

Expected behaviour

After a succesfull build errors should no longer be visible and intellisense should be working

Machine info

Ionide for F#
v7.5.2
.NET SDK (reflecting any global.json):
Version: 6.0.403
Commit: 2bc18bf292

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.403\

Host:
Version: 7.0.4
Architecture: x64
Commit: 0a396acafe

.NET SDKs installed:
2.1.801 [C:\Program Files\dotnet\sdk]
2.1.802 [C:\Program Files\dotnet\sdk]
2.2.401 [C:\Program Files\dotnet\sdk]
2.2.402 [C:\Program Files\dotnet\sdk]
3.1.102 [C:\Program Files\dotnet\sdk]
6.0.403 [C:\Program Files\dotnet\sdk]
7.0.202 [C:\Program Files\dotnet\sdk]

Additional context

Add any other context about the problem here.

[SIRHAMY]

+1 - this happens all the time.

I typically work in small projects so this seems to even happen with very small numbers of files / lines of code.

I most often see it when there's an error -> it seems like intellisense etc stops working after there error.

I will often find myself manually reloading VS Code every few minutes after I've changed code to kick off intellisense again / get it unstuck.

[TheAngryByrd]

Can you try with AdaptiveLSPServer enabled?

[SIRHAMY]

@TheAngryByrd - This seems to have helped tremendously. Turned it on earlier today and haven't had to reload VS Code once due to intellisense hanging.

[ntwilson]

In my experience, the Adaptive LSP server helps, but the problem is still there for larger codebases. From the looks of it from the little status bar text at the bottom, it seems like it gets stuck typechecking files in other projects and can take a minute or so to finally get back to typechecking the file I'm actually editing. Then errors or intellisense gets "frozen" until it finally loops back around to the file I'm in.

Maybe this is a different problem though because it does eventually unfreeze?

[TheAngryByrd]

Then errors or intellisense gets "frozen" until it finally loops back around to the file I'm in.

I think this is an issue with thread exhaustion that I've slowly been tackling. ionide/FsAutoComplete#1088 will help solve some more of them.

I've noticed there are still some issues where vscode/ionide asks for fsharp/signatureData way too much, as in every key stroke. The bigger the file, the worse this is, potentially sending hundreds of requests which all start trying to use the threadpool. Similarly fsharp/pipelintHint gets called very often too and is quite expensive for larger files. (Large files in general are hard to process) Maybe debouncing those calls would be be a way to mitigate more if that PR doesn't help with those issues.

[TheAngryByrd]

Also for bigger projects, make sure to turn off FSharp.codeLenses.references.enabled. Getting references across your entire solution is just going to be slow as it needs to typecheck every file underneath your current file.

See https://ionide.io/Editors/Code/options.html#recommended-settings-for-larger-solutionprojects with some recommendations I have for bigger projects.

[ntwilson]

FWIW, this subjectively seems to be improved a bit with Ionide 7.5.3 and using the recommended settings for larger solutions, but I still observe cases where it appears to hang for quite some time (minutes, not seconds).

Would it be considered at all if I made a feature request to just disable the typechecking of dependent files that you don't even have open? That would resolve a lot of this I think no matter how big your solution got.

[TheAngryByrd]

Would it be considered at all if I made a feature request to just disable the typechecking of dependent files that you don't even have open? That would resolve a lot of this I think no matter how big your solution got.

I think we would take this contribution, however this may not be as beneficial as you think, as you pointed out previously:

From the looks of it from the little status bar text at the bottom, it seems like it gets stuck typechecking files in other projects

This is because if you have when you ask for typechecking of a file, there's a whole set of things the F# compiler has to do be able to typecheck it. This include things like getting reference assembly information and typechecking dependent files. To see this a bit better, you can enable OpenTelemetry traces in FSAC.

To illustrate the point a bit more, if we did have this option. let's say you have files 1.fs-100.fs in a project. If you have file 1.fs, 25.fs, and 80.fs open, when you edit and save 25.fs, it won't typecheck 1.fs-24.fs but it will have to typecheck everything between 25.fs-80.fs even though you don't have anything in between open. And when looking at the notifications you'll see it being "stuck" on 80.fs. The other downside of not checking anything below 80.fs is you may not know you have errors in 81.fs-100.fs. There is benefit when you only have 23/24/25.fs open but this example is the kind of thing to consider.

[ntwilson]

Thanks for taking the time for such a detailed description! I see your point. That feature would probably add a lot of complication and user confusion (and maybe lead to a lot of false issues being created).

What is the recommendation right now for solutions large enough to have really long wait times? Just open one project at a time when heavily editing one or a couple files within a single project? I've noticed that Ionide version 6 is much quicker when working with large solutions. Do we expect this to improve with some kind of fix in the future, and we should sit tight with v 6 until that lands? Or if intellisense stops working for minutes at a time, does that just indicate that your solution is too large for what Ionide intends to support?

Sorry if I'm sounding negative here. I really appreciate the Ionide project and all the hard work that goes into it. I'm not trying to criticize, just figure out the expectations.

[TheAngryByrd]

Thanks for taking the time for such a detailed description! I see your point. That feature would probably add a lot of complication and user confusion (and maybe lead to a lot of false issues being created).

Yeah it's unfortunate that there's no straight forward answer to fixing large solutions.

What is the recommendation right now for solutions large enough to have really long wait times? Just open one project at a time when heavily editing one or a couple files within a single project? I've noticed that Ionide version 6 is much quicker when working with large solutions. Do we expect this to improve with some kind of fix in the future, and we should sit tight with v 6 until that lands? Or if intellisense stops working for minutes at a time, does that just indicate that your solution is too large for what Ionide intends to support?

Basically without some type of repro, it's unlikely anything is going to be changed. And I understand the complexity of a solution is hard to replicate. I work on a fairly large solution as well and I see most of the time spent in the F# compiler, which we don't have too much control over. Editing one of our top most files can mean a few minutes type checking the rest of the solution.

As far as what you can do, you can:

1. Help with FSAC itself by profiling it and seeing if there are hot spots that we can address.

2. To improve some type checking times, signature files can help out a lot here, especially if you have large files with an small public interface. We did a session on Amplifying FSharp with using the new Graph Based type checking and signature files to improve the compile times of FSAC itself.

[TheAngryByrd]

Closing this as I don't see this on my larger work project and no repro was given.