Use CommentRanges from the parsed output
#11591
Merged
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
dhruvmanila
force-pushed
the
dhruv/token-flags
branch
from
f1d51f8
to
b52b83c
Compare
dhruvmanila
force-pushed
the
dhruv/comment-ranges
branch
from
12c3707
to
d49b4fc
Compare
dhruvmanila
force-pushed
the
dhruv/token-flags
branch
from
b52b83c
to
436f6a5
Compare
dhruvmanila
force-pushed
the
dhruv/comment-ranges
branch
from
d49b4fc
to
817ef3e
Compare
MichaReiser
approved these changes
May 29, 2024
There was a problem hiding this comment.
Nevertheless, the struct will be owned by the parsed output. So, all references should now use the struct from the parsed output instead of the indexer.
I'm not sure if this will remain true if we build the comment ranges after parsing. One of the benefits of building it after parsing is that we can make it optional and only run it when the comment ranges are needed.
Comment on lines
170
to
172
| if !checker | ||
| .indexer() | ||
| .program() | ||
| .comment_ranges() |
There was a problem hiding this comment.
I think this is a case where it could make sense to simply expose comment_ranges on checker so that it matters less where the comment ranges are actually stored. I don't think it is necessary to change now but it would e.g. help if we move comment ranges in the future again.
Overall, I think this is a weakness of our checker API. Lint rules need to know too much about individual representations. I think it would be better if there's a single context and the rules could simply ask:
- Give me the comment ranges
- give me the indexer
- give me the line index
etc. without having to do deep drilling.
There was a problem hiding this comment.
Yeah, I completely agree with your sentiment.
dhruvmanila
added a commit
that referenced
this pull request
May 30, 2024
## Summary This PR updates the usages of `CommentRanges` from the `Indexer` to the parsed output. First, the `CommentRanges` are now built during the parsing step. In the future, depending on the performance numbers, it could be updated to be done after the parsing step. Nevertheless, the struct will be owned by the parsed output. So, all references should now use the struct from the parsed output instead of the indexer. Now, the motivation to build `CommentRanges` while parsing is so that it can be shared between the linter and the formatter as both requires it. This also removes the need to have a dedicated method (`tokens_and_ranges`). There are two main updates: 1. The functions which only require `CommentRanges` are passed in the type directly 2. If the functions require other fields from `Program`, then the program is passed instead
dhruvmanila
added a commit
that referenced
this pull request
May 31, 2024
## Summary This PR updates the usages of `CommentRanges` from the `Indexer` to the parsed output. First, the `CommentRanges` are now built during the parsing step. In the future, depending on the performance numbers, it could be updated to be done after the parsing step. Nevertheless, the struct will be owned by the parsed output. So, all references should now use the struct from the parsed output instead of the indexer. Now, the motivation to build `CommentRanges` while parsing is so that it can be shared between the linter and the formatter as both requires it. This also removes the need to have a dedicated method (`tokens_and_ranges`). There are two main updates: 1. The functions which only require `CommentRanges` are passed in the type directly 2. If the functions require other fields from `Program`, then the program is passed instead
dhruvmanila
added a commit
that referenced
this pull request
Jun 3, 2024
## Summary This PR updates the usages of `CommentRanges` from the `Indexer` to the parsed output. First, the `CommentRanges` are now built during the parsing step. In the future, depending on the performance numbers, it could be updated to be done after the parsing step. Nevertheless, the struct will be owned by the parsed output. So, all references should now use the struct from the parsed output instead of the indexer. Now, the motivation to build `CommentRanges` while parsing is so that it can be shared between the linter and the formatter as both requires it. This also removes the need to have a dedicated method (`tokens_and_ranges`). There are two main updates: 1. The functions which only require `CommentRanges` are passed in the type directly 2. If the functions require other fields from `Program`, then the program is passed instead
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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.
Summary
This PR updates the usages of
CommentRangesfrom theIndexerto the parsed output.First, the
CommentRangesare now built during the parsing step. In the future, depending on the performance numbers, it could be updated to be done after the parsing step. Nevertheless, the struct will be owned by the parsed output. So, all references should now use the struct from the parsed output instead of the indexer.Now, the motivation to build
CommentRangeswhile parsing is so that it can be shared between the linter and the formatter as both requires it. This also removes the need to have a dedicated method (tokens_and_ranges).There are two main updates:
CommentRangesare passed in the type directlyProgram, then the program is passed instead