-
Notifications
You must be signed in to change notification settings - Fork 128
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
Provide features on singletons #2188
Conversation
7e818de
to
568b345
Compare
6e85194
to
f0c87e5
Compare
afa3ff3
to
c4a8708
Compare
89a063f
to
ea7a450
Compare
@response_builder = response_builder | ||
@global_state = global_state | ||
@index = T.let(global_state.index, RubyIndexer::Index) | ||
@type_inferrer = T.let(global_state.type_inferrer, TypeInferrer) | ||
@node_context = node_context | ||
@typechecker_enabled = typechecker_enabled |
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 for this PR, but I wonder if we can avoid the need to pass typechecker_enabled
by instead determining this from type_inferrer
, i.e. if type_inferrer
is nil that means a typechecker is in use?
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.
For now, that would work. However, long term we would like to integrate more deeply with Sorbet and do something like:
- First ask Sorbet if it can find the most accurate definition
- If a definition was found, use that and do nothing else
- If not found, fallback to the Ruby LSP behaviour (we'd need the inferrer here)
Motivation
Second to last step for #1938. The only part missing is proper linearization of singleton ancestors, which I'm working on.
This PR uses the type checker introduced in #2187 to provide go to definition, hover, completion and signature help inside singleton contexts.
Implementation
I split each feature by commit:
The only notable part of the implementation is completion. When invoking methods on a singleton, we know the receiver type, which means we can show all available methods immediately when the user types the dot.
To support that, we needed a few extra changes:
Automated Tests
Added tests for all the features.
Manual Tests
Launch the LSP on this branch and start testing features for things invoked directly on singletons (remember that ancestors are still missing for now!).
singleton_demo.mov