Skip to content

Rubocop results are not displayed on VSCode when opening a file larger than approximately 104 kilobytes #3087

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cc-harashima opened this issue Jan 23, 2025 · 3 comments
Labels
bug Something isn't working vscode This pull request should be included in the VS Code extension's release notes

Comments

@cc-harashima
Copy link

Description

Ruby LSP Information

VS Code Version

1.96.0

Ruby LSP Extension Version

0.8.16

Ruby Version Manager

rbenv

gem Versions

rubocop 1.68.0

Reproduction steps

  1. Start the Ruby LSP using a VSCode
  2. Prepare a Ruby file smaller than 103KB and confirm that Rubocop warnings are displayed on VSCode.
  3. Add content to the file to exceed approximately 104KB, and observe that Rubocop warnings disappear from the screen
@cc-harashima cc-harashima added bug Something isn't working vscode This pull request should be included in the VS Code extension's release notes labels Jan 23, 2025
@vinistock
Copy link
Member

vinistock commented Jan 23, 2025

Thank you for the report, but this is not a bug. Diagnostics run on every keypress, putting them in the critical flow for performance in language servers.

Unfortunately, in files that are too large, collecting RuboCop diagnostics starts taking too long. This is primarily due to the double-parse required, since RuboCop uses an API different from Prism and the fact that RuboCop doesn't use the listener approach included in the Prism API, which would allow the Ruby LSP to gather diagnostics in a single traversal of the AST (massively improving performance).

Since diagnostics starts taking 1 second or more after a certain file size, we intentionally disable it to avoid having the editor start lagging. Otherwise, it starts to become unresponsive and the experience degrades fast.

I believe finishing #1849 will improve the situation, as it gets rid of the double-parse.

@vinistock vinistock closed this as not planned Won't fix, can't repro, duplicate, stale Jan 23, 2025
@andyw8
Copy link
Contributor

andyw8 commented Jan 23, 2025

Also, there should be a line in the output window saying: "The file (path) is too long. For performance reasons, semantic highlighting and diagnostics will be disabled."

@cc-harashima
Copy link
Author

I understood. thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working vscode This pull request should be included in the VS Code extension's release notes
Projects
None yet
Development

No branches or pull requests

3 participants