-
Notifications
You must be signed in to change notification settings - Fork 107
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
Improve support for navigating to definitions in external modules #3263
Improve support for navigating to definitions in external modules #3263
Conversation
cc @kritzcreek |
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.
Haven't looked all that closely but the changes seem reasonable. Either way I'd expect a change like this to also include a test.
Hi Ryan, thanks for the PR(s)! I'm in the middle of a family emergency so won't get a chance to review today. Hopefully someone else can oblige or I'll get to it in the next few days |
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.
LGTM (though I'm a stranger to these parts).
Thanks for contributing and sorry for the delay!
(merging with master to kick off another build) |
@rvanasa if you cannot merge, try adding the |
@ggreif it looks like I would need write permissions to add a label to the PR. Thanks for merging when you get the chance! |
Fab! Thanks again! |
This PR adds straightforward "go to definition" support for Motoko's pattern-style import syntax. For example, `import { v|als } "mo:base/Array"` and `v|als(x)` (where `|` represents the cursor) will correctly navigate to the corresponding `Array.vals` declaration. As with existing language server functionality, these changes do not yet account for variable shadowing. However, the updated `parse_module_header` function already parses import patterns such as (`import {alias = field} "..."`) based on the proposed generalized import syntax (#3076). Please let me know if additional explanation would be helpful for any of these changes. I also included four test cases to cover the newly expected behavior of `definition_handler` and `parse_module_header`. Tested in VSCode on WSL using the official Motoko extension. Fixes #3078 Supersedes #3263 CC @kritzcreek, @crusso, @matthewhammer
I rewrote most of
definition_handler
to account for edge cases related to finding definitions in external files.It's now possible to jump to the definition of an import identifier (rather than having to click on a qualified member name). For example,
import M|ap "HashMap"
(where|
is the cursor) jumps to the top ofHashMap.mo
instead of doing nothing (fixes Buggy behaviour with go to definition vscode-motoko#17).The new implementation also has a more permissive default behavior for missing declarations. In cases where the module path is known but the qualified symbol is unknown, the language server attempts to direct the user to the relevant module. This is mostly intended as a fallback for situations where the index is missing an expected declaration, such as when the other file has a syntax error.
Possible future improvements:
module
or equivalent keyword (when possible) rather than the top of the fileimport
keyword)languageServer
support for explicit symbolimport
s #3078 (currently experimenting with this)Passes all tests on my WSL setup and works as expected in VSCode with the official Motoko extension.
(@matthewhammer)