Diagnostics in files outside of a workspace shouldn't be reported

[wscnd]

OS Version: Darwin Kernel Version 23.4.0

VS Code Version: 1.87.0-insider 4f2ff19ecacffa0aa4874db4d63ed4e899d98431

Go Version: go1.22.1 darwin/arm64

Code Repository (if open source):

Feature request: - What is the problem you want to solve? When opening files from the go lib, ex net/http the extension checks files from it, adds them to the Problems tab & causes vscode to lag/stutter.

- What did you try to solve it? Tried adding to all exclude folder vscode settings **/homebrew/** but it still checks all files.

- What you propose us to change in the product? Add an option to explicitly add excluded folders or inherit it from "search.exclude" setting from vscode.

[tooltitude-support]

@wscnd Thank you for the feedback.

Which version of of tooltitude do you use? The error which you reported, shouldn't lead vscode to stutter (it worries me the most in the report). Could you verify that it's tooltitude which consumes cpu from the top command.

I disabled error checking for files outside of modules from your project. This should be available in 0.70.0 which will be released tomorrow.

[tooltitude-support]

@wscnd I also changed the title of the issue. It better aligns with the problem you described. Hope you don't mind.

[wscnd]

@tooltitude-support Hello, thank you for the support. I'm currently using v0.69.0. With htop I could see it going up to 50% when I open the definition for thenet.http.Handler. If there's any more information you'd like for me to add let me know. Thanks for the amazing extension, having a lot of fun with it ☺️

[tooltitude-support]

@wscnd Thanks!

0.69 is the latest version. I looked at the file, and it's around 4k LOC, so it's likely the size of the file which might slow stuff down. In 0.70.0, nothing will be spent on checking it, but we definitely want to support files of this size, so it makes sense for us to investigate what's going on with it in the future.

[tooltitude-support]

@wscnd Also, I noticed that gopls also checks this files, as well as runs inspections. Did you see them spike in the top/activity monitor?

Could you share how much time does gopls spends compared to tooltitude. It should be available in the CPU time column in the CPU tab of the activity monitor (if the tooltitude process spends much more time than gopls, then it looks like something wrong with the tooltitude process).

[tooltitude-support]

@wscnd

I run it on the 0.70.0 version with checks for deps on, and here's what I got in the output:

2024-04-10T01:15:27.642310Z  INFO opened doc: file:///home/linuxbrew/.linuxbrew/Cellar/go/1.22.1/libexec/src/net/http/server.go
2024-04-10T01:15:27.642328Z  INFO lsp_request{method="textDocument/codeAction" id=14}: close time.busy=15.8µs time.idle=2.47µs
2024-04-10T01:15:27.642986Z  INFO run_file_check: new
2024-04-10T01:15:27.671976Z  INFO run_file_check:broken_refs_checker: new
2024-04-10T01:15:27.672007Z  INFO run_file_check:broken_refs_checker: close time.busy=13.4µs time.idle=18.3µs
2024-04-10T01:15:27.672016Z  INFO run_file_check:shadow_decl_checker: new
2024-04-10T01:15:27.679489Z  INFO run_file_check:shadow_decl_checker: close time.busy=7.47ms time.idle=3.11µs
2024-04-10T01:15:27.679500Z  INFO run_file_check:dataflow_checker: new
2024-04-10T01:15:27.685406Z  INFO run_file_check:dataflow_checker: close time.busy=5.90ms time.idle=3.20µs
2024-04-10T01:15:27.686715Z  INFO run_file_check: close time.busy=43.7ms time.idle=11.4µs

Could you try to find a similar line of logs for your project. It looks like it takes very little time, 43.7ms all in all).

P.S. You could find logs by going to the bottom pane, the same pane where terminal is located. You should go to the output section, and choose tooltitude in the dropdown.

[tooltitude-support]

@wscnd 0.70.0 is out now. We shouldn't check the opened file any longer. Please, reopen this issue if the issue repeats. If you experience performance problem, please open a separate issue.