Script type-checking randomly stops working until I rename the file [Backer]

[nhirschey]

Describe the bug**

I've now run into this multiple times on different scripts, so filing a bug with logs. I'm writing fsdocs scripts. Things go great, but then at some point type checking stops working. I can type 1+1.0 and there are no red squigglies. Though line lens, code completion, and sending to fsi still works.

But ... if I get in this state and rename the file, such as changing a not working file name file.fsx to file1.fsx or fil.fsx, voila type checking comes back.

I do not have a simple reproducible example. But I did collect detailed logs and do a file diff to identify differences. The main difference seemed to be that the file that doesn't work sent semantic tokens before it recieved the fsharp/fileParsed notificatoin. The file that worked got the fsharp/fileParsed notification before it sent semantic tokens.

Here is a gist with logs from two versions of a script, where the only difference is one character in the file name: https://gist.github.com/nhirschey/e7e7894cf15de913f85dc03df2dfcedb

Comparison of the log files, showing where they differ:

Traces start out the same in both files, in this order

• Sending request 'textDocument/documentSymbol
• Sending notification 'textDocument/didClose'
• Sending notification '$/cancelRequest'
• [LSP Server] HandleClientMessage - Error {"Code": -32601, "Message": "Method not found", "Data": null, "$type": "Error"} when handling notification {"Version": "2.0", "Method": "$/cancelRequest", "Params": {"Value": [[[]]], "$type": "Some"}, "$type": "Notification"}
• Received response 'textDocument/documentSymbol
• Sending notification 'textDocument/didOpen
• Sending request 'textDocument/codeAction
• Sending request 'textDocument/documentSymbol
• Received response 'textDocument/codeAction
• Received response 'textDocument/documentSymbol

Now the traces diverge in both logs at line 1974. Numbers in brackets are line numbers

The file that does not typecheck.

• [1974] Sending request 'textDocument/semanticTokens/full
• [1982] Received response 'textDocument/semanticTokens/full
• [6309] Received notification 'fsharp/fileParsed
• [6315] Sending request 'fsharp/lineLens
• [6323] Sending request 'fsharp/pipelineHint
• [6329] Received notification 'textDocument/publishDiagnostics. The diagnostics are empty. They're missing the typecheck errors.

...lots more messages...

• [7650] Sending request 'textDocument/codeAction. This sends a request for the line with the error, but the resulting diagnostics are empty

The file that correctly typechecks the file

• [1974] Received notification 'fsharp/fileParsed'
• [1980] Sending request 'fsharp/lineLens
• [1988] Sending request 'fsharp/pipelineHint
• [1994] Received notification 'textDocument/publishDiagnostics'. This contains correct typecheck error messages
• [2036] Sending request 'textDocument/semanticTokens/full
• [2044] Received response 'fsharp/lineLens

...lots more messages...

• [7839] Sending request 'textDocument/codeAction. This sends a request for teh line with the error, and the diagnostics has the typecheck error.

Machine info

• .NET SDK version: 5.0.200-preview.21079.7 (I also got it on 5.0.103)
• Ionide version: 5.3.2

Version: 1.54.0-insider (user setup) Commit: 192c817fd350bcbf3caecae22a45ec39bae78516 Date: 2021-02-19T05:14:28.632Z Electron: 11.2.3 Chrome: 87.0.4280.141 Node.js: 12.18.3 V8: 8.7.220.31-electron.0 OS: Windows_NT x64 10.0.19042

[open-collective-bot[bot]]

Hey @nhirschey :wave:,

Thank you for opening an issue. We will get back to you as soon as we can. Also, check out our OpenCollective and consider backing us.

https://opencollective.com/ionide

PS.: We offer backer support for all backers. Don't forget to add backer label when you start backing us :smile:

[nhirschey]

The singularity is still a long ways off ; ) https://opencollective.com/nicholas-hirschey

[cartermp]

bad bot!

[baronfel]

If changing the file name makes things work again, then this sounds like some kind of typecheck-cache/file watcher issue in FSAC. We should double-check the way that script filenames are cached/computed/checked, since filenames are the primary key for our caches.

[nhirschey]

Some things to add:

1. Without changing the filename, I have also gotten type checking to come back by deleting several (working) lines of the script. The workflow would be you have a perfectly working and type checked script, and you start adding to it someplace. Then you notice that typechecks stop working.
2. I have suspected that it could be related to this issue I just filed: https://github.com/ionide/ionide-vscode-fsharp/issues/1502? I have tried converting all (** *) comments to (* *) comments with find and replace, but that didn't fix things. But when deleting comments entirely, it's unclear if it's something about the changed file size or line length or something specific to the comments.

[nhirschey]

Hey, I just ran into this again while live coding for my students. Good news is that I have new debug info for how to get intellisense back without renaming the file, and it worked on two consecutive classes where this occurred, so I think it's repeatable (if you get into the bad state that I don't know how to reproduce but that I get into regularly):

I was able to get intellisense typechecking to come back if I

1. Closed the file.
2. Closed the folder (though VS Code is still open).
3. Re-opened the folder
4. Re-opened the scipt

After that, intellisense properly caught errors.

[nhirschey]

I continue to hit this all the time (scripts not being type-checked), but I now have a reproducible example that might help debug.

Caveat: my general problem is that I will be working on a script and type-checking randomly stops (for example above logs from the original issue). But I cannot reproduce a random error; this is only a reproduction of a script that isn't type checked, but I hope this is a special case of the general bug.

1. Create a blank folder and open it in code:

mkdir no-type-check
cd no-type-check
code .

2. Inside code, the folder is now opened so f# scripts should get type checked. Now open the terminal in vs code and create a blank script.

code test.fsx

3. Save the script with ctrl+s. The script is now saved in an opened folder, so ionide should be type checking it. Now paste the following list in with an error on line 5. Intellisense will work, but there is no type checking until you close everything and reopen to force ionide to type check things (note: occasionally it would not reproduce, but if I completely deleted the folder and started over with these steps I seem to be able to reproduce consistently). A screenshot showing no type-checking is at the bottom.

let x =
    [
        "A"
        "A"
        0
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        "a"
        ""
    ]

[Booksbaum]

I think same issue as this and #1518 -- but not just in Script files, but normal F# code files in F# project too.

While trying to figuring out what's happening, I found these reproduction steps:

(In short: no compiler errors & warnings for F# tabs that were front tabs at time of VS Code start)

Steps to reproduce with existing project

• Open project, open a (previously not opened) F# code file, write something erroneous. Error should be highlighted. Keep Tab with F# file open.
• Restart VS Code (or Ctrl+Shift+p -> Developer: Reload Window)
• -> No Error should be displayed -- neither highlighted in source code file, nor in Problems view (in bottom panel)

Steps to reproduce with fresh example project:

• move into empty dir, or make new one (mkdir tmp; cd tmp)
• Create new project: dotnet new console -lang f#
• open in VS Code: code .
• open file Program.fs in Tab.
• introduce error: For example: change %s to %i in printfn. -> error should be highlighted
• Reload VS Code with Ctrl+Shift+p -> Developer: Reload Window
  -> Error isn't highlighted any more, neither does it show in the Problems view (not shown in image)

To restore error highlighting:

• Ensure Tab with Program.fs is not front tab (active, selected, visible tab). For example by either:
  • Close Tab with Program.fs
  • Open another file like tmp.fsproj
  • Create new file via Ctrl+n. File doesn't need to be saved to disk -- a fresh untitled file is enough
• Restart Vs Code (or Developer: Reload Window)
• Switch back to Program.fs Tab -> error should be visible

Additional

• Closing the file and reopening doesn't restore error highlighting.
• Errors are still highlighted for source files that weren't front tabs at VS Code start -> it really just happens for front tabs at VS Code start.
• No errors applies to ALL front tabs: multiple views (rows, columns) with F# files visible -> neither of these get any errors. (Even when moving or opening in another view)
• Normal code highlighting, Code lenses, Tooltips, Code Completion, etc. still work -- it's really just compiler errors and warnings
• Rename file and then rename it back doesn't restore compiler error (Program.fs -> Program2.fs -> Program.fs)
  • Renaming the file and adjust the fsproj to the new file enables error for that file. I guess it's basically a new file that must be parsed instead of reusing some cached state.
• LSP:
  • When compiler error is showm it's received in textDocument/publishDiagnostics. When error is in a front tab, no publishDiagnostics notification (or any other notification) contains the compiler error
    -> Seems to be an issue in FsAutoComplete, not on the Ionide/VSCode Client side.

[nhirschey]

I can reproduce @Booksbaum 's bug. It feels very similar to the script bug, though it's a bit better because if the file is open it looks like I can close code and reopen and the error shows up. However, with a script you can close code and reopen and type checking doesn't come back. Script type checking only comes back if you close the file before closing code.

[Martin521]

To my observation, this happens a) for new files that you add to the project b) for the file that was open (visible) when you last closed VS Code.

[nhirschey]

@Martin521 that's a good observation. I can consistently switch between "type checking working" and "type checking not working" by having a file open or closed when I hit ">developer reload" window. If the file is open when I hit reload window type-checking is broken after the refresh. Here's a demonstration where I created a new folder and have a single 2-line "test.fsx" file in the folder.