vscode-tree-sitter: Extension host crashes on `unhandledRejection`

This issue is mostly FYI vscode-tree-sitter crashes the extension host process in case of any unhandled promise rejections. Unfortunately, you are not able to do much on the extension side. Most likely the culprit is your web-tree-sitter dependency. The related issue is https://github.com/tree-sitter/tree-sitter/issues/571#issue-577509898.

At the end of the day vscode-tree-sitter damages the extension host process when this happens and all other extensions altogether.

The initial issue was reported in https://github.com/rust-analyzer/rust-analyzer/issues/3515#issuecomment-596207493 to the unrelated rust-analyzer repo.

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 1
  • Comments: 22 (1 by maintainers)

Most upvoted comments

May be it’s this one?

https://github.com/EvgeniyPeshkov/syntax-highlighter

I recognize the author from this discussion.

One other thing to note, there seems to be another extension (I believe it’s called syntax highlighter) that uses the tree sitter, but seems to be actively maintained. It might be worthwhile to switch to focusing on that repo.

If you copy the commands, resources, and settings folder into a fork of that actively maintained repo the commands/start will most likely still work and autoinstall the node-gyp dependencies of that repo. The compile command might be different, but I’m sure they’d have an npm script for it

@sogaiu thanks for the detailed feedback. Looks like I screwed up when I changed that tsconfig. I was getting a false positive when testing changed because I had already generated an out folder.

I definitely generated several working build.vsix files, but the bad news is now I am essentially stuck at your same issue. I went back through all the commits I made, generating a build.vsix at each one, and so far all of them crash the entire extension host without leaving a message. I have no idea what changed.

I rolled back some code-organization changes on master (like the one that added emit: false), and put all the most recent changes such as improving the compile script (deletes out folder and build.vsix to prevent false positives now) on a wip branch.

Now that I think about it, when I was exploring previous commits it also reverts the project compile command, so I probably need to test older commits while using the newer command. I’ve got some other things to take care of though so it might be a while before I’m able to pick back up on this topic.

There’s been a lot of mysterious crashes on windows coming from the compiled WASM parsers for specific languages. I recently published a new version where I updated to the latest versions of all deps, rebuilt the WASM files, and removed verilog, which seemed to be causing problems. Hopefully that has fixed it…