Add API for specifying the included ranges of a Parser
#127
Conversation
This file contains 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
Its implementation is based on that of `__comparePoints`, and as such it has been named `__compareRanges`
This includes: - `POINT_ORIGIN`, which corresponds to (0,0) - `POINT_MAX`, which corresponds to the point with maxed out `x` and `y` - `RANGE_FULL`, which corresponds to `DEFAULT_RANGE` from `lexer.c`
Added bridge to the corresponding tree-sitter method (ts_parser_included_ranges). However, unlike that method, the Java implementation will return an empty `Collection` if no ranges were included. Makes use of all the previously introduced utilities.
The All-Args constructor should be publicly visible, while the one that takes in a `Node` should be package-private. Not sure how this oversight occurred in the first place.
Most of it was reorganised in order to be more easily read. In terms of content, it remains largely the same. However, a minority of the text was reworded for added clarity.
Comparing ranges did not make sense the way we were doing it initially. It's far better to do this on the Java end, and just assume that ranges are properly ordered when they are passed into the native code. The functionality of `__compareRanges` was stripped down into a dedicated `__pointEqual` and `__rangeEqual`, which are fare more practical and make more sense. I'm not sure if these native implementations should be used from the Java code, especially since its such simple code. We do implement `Point#compareTo` natively, but even in that case I am debating whether this is a good idea. At the end of the day, the `RANGE_FULL` variable is now `RANGE_DEFAULT`, and the method to check if a `TSRange` matches it is now aptly named `__isDefaultRange`.
There is no sense in constructing `Range` instances that have negative values in terms of byte offsets or coordinates. By using a `Builder`, we can more easily enforce preconditions that clients should respect.
Currently only tests `Range#Builder` functionalities
Added native implementation for a `Parser` mutation method that, as the name implies, will set the list of ranges that are considered when parsing documents. Note that while documented, the methods do not yet check if the range precondition is satisfied or not. That will be introduced in one of the subsequent commits.
This validator checks if all the elements of an array: - Are not null; - Respect the pairwise `Range` invariant specified in the JavaDoc
All the exceptional builder and setter test cases have been grouped into two dedicated parametrized tests. Other than that, this commit also introduces some additional assertions to existing tests: - `ParserTest#testSetIncludedRanges` - `ParserTest#testBuilder` - `ParserTest#testToBuilder`
The method did not work as intended with points containing negative coordinates. This is because on the JNI end, it was being unmarshalled into a `TSPoint`, whose coordinates are all defined as _unsigned_ ints. The `__comparePoints` will remain, as it seems to work fine with the native methods that use it.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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.
This PR introduces two new instance methods:
Parser#getIncludedRangesParser#setIncludedRanges(List)Parser#setIncludedRanges(Range[])The Parser#Builder was also modified to include new methods for specifying and clearing included ranges:
Parser#ranges()Parser#ranges(List)Parser#ranges(Range[])Parser#range(Range)