-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate semantic highlighting to YARP #1000
Conversation
Co-authored-by: Alexandre Terrasa <[email protected]>
9e46e6f
to
2f8eb3b
Compare
attr_reader :parent | ||
|
||
sig { params(parent: T.nilable(ParameterScope)).void } | ||
def initialize(parent = nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nit) Since the only places where we don't pass an argument is in the tests, might it simplify things a little to make this a required parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't pass an argument when we instantiate it for the first time in SemanticHighlighting#initialize
. It would also not be correct to always require a parent given that the global scope doesn't have one.
sig { params(name: T.any(Symbol, String)).returns(T::Boolean) } | ||
def parameter?(name) | ||
sym = name.to_sym | ||
@parameters.include?(sym) || ([email protected]? && @parent.parameter?(sym)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@parameters.include?(sym) || (!@parent.nil? && @parent.parameter?(sym)) | |
@parameters.include?(sym) || @parent&.parameter?(sym) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That fails typechecking because instead of returning T::Boolean
it returns T.nilable(T::Boolean)
.
# For each capture name we find in the regexp, look for a local in the current_scope | ||
Regexp.new(content, Regexp::FIXEDENCODING).names.each do |name| | ||
# The +3 is to compensate for the "(?<" part of the capture name | ||
capture_name_offset = T.must(content.index("(?<#{name}>")) + 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker, but it seems there are some other ways of representing named captures:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the \k<>
is a backreference to the named capture and not another way to create named captures. The idea is for you to do this
/(?<group>(something|other))(\k<group>)/
# ^ this captures group ^ this references the captured group
@@ -96,15 +96,12 @@ def test_encoded_modifiers_with_some_modifiers | |||
private | |||
|
|||
def stub_token(start_line, start_column, length, type, modifier) | |||
location = YARP::Location.new("", 123, 123) | |||
location.expects(:start_line).returns(start_line).at_least_once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nit) Isn't .at_least_once
redundant? An expectation would fail if never triggered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It gets triggered more than once, so this is necessary. By default, Mocha fails if an expectation gets hit twice.
Co-authored-by: Alexandre Terrasa <[email protected]>
Co-authored-by: Alexandre Terrasa <[email protected]>
* Temporarily disable .github/workflows/lsp_check.yml * Temporarily disable some tests * Preparation for YARP migration * Migrate DocumentSymbol request to YARP * Migrate Hover request to YARP * Migrate PathCompletion request to YARP * Migrate Sorbet request to YARP * Migrate InlayHints request to YARP * Migrate ShowSyntaxTree request to YARP * Migrate SelectionRange request to YARP * Migrate Definition request to YARP * Migrate Diagnostics request to YARP * Migrate CodeActionResolve request to YARP * Update selection ranges expectations * Fix rebase discrepancies * Add YARP RBI annotations (#978) * Migrate code lens to yarp (#979) Migrate CodeLens to YARP * Update `SERVER_EXTENSIONS.md` for YARP (#984) Co-authored-by: Andy Waite <[email protected]> * Update text references from Syntax Tree to YARP (#986) Co-authored-by: Andy Waite <[email protected]> * Fix rebase discrepancies * Migrate folding range to YARP (#980) * Fix rebase discrepancies 3 * Migrate semantic highlighting to YARP (#1000) Co-authored-by: Alexandre Terrasa <[email protected]> * Migrate document highlight to YARP (#1005) * Simplify block locals handling in semantic highlighting (#1011) * Fix latest breaking changes * Make folding range a listener (#1013) * Migrate DocumentLink request to YARP (#982) * Migrate DocumentLink to YARP * Only parse comments where needed * Fix type * PR feedback * Fix argument order * Re-enable DocumentLink integration test --------- Co-authored-by: Andy Waite <[email protected]> * Re-enable CI (#1022) * Re-generate YARP RBIs * Re-enable tests * Fix typechecking errors * Use locations for creating document symbol entries --------- Co-authored-by: Andy Waite <[email protected]> Co-authored-by: Andy Waite <[email protected]> Co-authored-by: Alexandre Terrasa <[email protected]>
Motivation
Closes #884
Migrate semantic highlighting to YARP.
Implementation
This PR adds a parameter scope implementation. This is a much simpler implementation than the scopes we contributed to SyntaxTree. It only tracks the parameters for the current scope and nothing else - which we use to highlight parameters consistently.
Other than that, the rest is just adding the necessary visits and changing node types.
Automated Tests
Most tests didn't need any changes, but some new tokens are now being pushed in a few cases. For example,
<<
used to not be considered aCallNode
, but it now is and so we get a token for that.