Skip to content

Invalid ranges returned from tree_house::injections_query::intersect_ranges #35

Closed

Description

@sruggier

So, I started using Helix earlier this week, and have been enjoying its performance, the editing model, and the fact that all of it is written in Rust. So much so that when I hit this problem, I took a bit of time to get the experimental debugging support working and started debugging Helix with itself.

I have a small Rust codebase that I wrote over a decade ago, and then mostly was unable to find time to develop since then. Nowadays, I worry that anyone who reads it might form the impression that this is the kind of code I'd write in Rust today, given half a chance, so I was going to spend a bit of time using Helix to make some improvements to it.

So I opened src/lib.rs, and noticed that there was no syntax highlighting. I was worried that maybe this was something I was doing wrong, so I started digging. Here's short summary of my investigation, and where the problem is coming from:

  1. In Helix's log, an event like this is emitted on each attempt to load the file: helix_view::document [WARN] Error building syntax for 'src/lib.rs': invalid ranges.
  2. With some trial and error, I found I could re-trigger the same log output efficiently by running :config-reload
  3. I then tried to find a more minimal reproducer. After removing enough code from the file, it would parse successfully, but by the time this happened, there were less than 200 lines left, and I narrowed it down to a comment, which felt like it wasn't useful to investigate further, for now, because there was nothing obviously noteworthy about the particular syntax element that was causing the problem to manifest.
  4. The same revision of the same tree-sitter parser works fine in Neovim, and the parser doesn't get updated very often, so I felt it was safe to assume that's not the problem.
  5. I was using the tip of Helix's main branch, so I tried building and running the last release tag, and the problem was still happening, so I could rule out any recent changes.
  6. I'm sure I could have gone back further and found a revision that didn't have this problem, but I'd noticed the tree-sitter related changes in the changelog and concluded that was probably not a useful data point. Reverting to the old implementation was clearly not going to be a useful workaround, either for me, or the upstream project.
  7. I started looking around in the source tree for where this error comes from, and saw that it's raised in highlighter/src/parse.rs.
  8. This is the point where I set up debugging. I could also have cloned tree-house, redirected the Helix build to use the local clone, and done some print-based debugging, but I was curious about how usable Helix's debugging feature currently is, having lived without in-editor debugging for a long time.
  9. In the debugger, I could see that there were three ranges listed, and the second one had a start_byte that was higher than end_byte.
  10. I looked around at where these ranges are constructed, reviewed all references, and saw that there's only one place that could be related, in highlighter/src/injections_query.rs.
  11. I spent a bit more time in the debugger, and found that this line, and the associated code path, is pushing an invalid range in.
  12. I couldn't get conditional breakpoints working while debugging, so I can't say that's the only source of invalid ranges from that function. It would be more efficient to use debug assertions to catch those as part of a fix for this, so it didn't make sense to keep using a debugger to investigate.

If anyone is planning to work on a fix, please comment here first, to prevent duplication of effort. Otherwise I'm probably going to work on it later today.

Activity

  1. added a commit that references this issue on May 30, 2026
  2. the-mikedavis commented on May 30, 2026

    @the-mikedavis
    Member

    Fixed by #36

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions