Have parse! rely on non-nil returned parser to determine success#772
Open
seamusriordan wants to merge 2 commits intoOlical:mainfrom
Open
Have parse! rely on non-nil returned parser to determine success#772seamusriordan wants to merge 2 commits intoOlical:mainfrom
seamusriordan wants to merge 2 commits intoOlical:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I found the underlying
vim.treesitter.get_parserfunction intree-sitter.parse!was always returning true in the first return value even in failure. e.g.with error (which is the final return value)
When the call is successful I get something like
with returned error message of
nil.I was able to trigger the failure with the
diffviewplugin by editing a lisp file in a git repo, closing neovim and opening it without arguments (i.e. without opening any files), then invoking:DiffviewOpen. I believe in this scenario conjure is invoked because it is associated with one of the buffers, but it is trying to callparse!all buffers, one of which does not have a treesitter language registered.This will have a followup PR for the tree-sitter completions to guard around failed parsing. I pulled this out separately as we've done general bug fixes like this in their own PRs.