Skip to content
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

Merged
merged 8 commits into from
Jun 3, 2022

Conversation

rvanasa
Copy link
Contributor

@rvanasa rvanasa commented May 23, 2022

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 of HashMap.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:

  • Using the start/end position of the module or equivalent keyword (when possible) rather than the top of the file
  • Providing the same functionality when the cursor is on the import string literal (and perhaps even the import keyword)
  • Supporting object pattern-style imports as mentioned in languageServer support for explicit symbol imports #3078 (currently experimenting with this)

Passes all tests on my WSL setup and works as expected in VSCode with the official Motoko extension.

(@matthewhammer)

@ghost ghost added the cla:agreed label May 23, 2022
@matthewhammer matthewhammer requested review from crusso and ggreif May 24, 2022 00:15
@matthewhammer
Copy link
Contributor

Thanks @rvanasa! I'm adding @crusso and @ggreif as reviewers.

@matthewhammer
Copy link
Contributor

cc @kritzcreek

Copy link
Contributor

@kritzcreek kritzcreek left a 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.

@crusso
Copy link
Contributor

crusso commented May 24, 2022

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

Copy link
Contributor

@crusso crusso left a 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!

@crusso
Copy link
Contributor

crusso commented May 30, 2022

(merging with master to kick off another build)

@crusso
Copy link
Contributor

crusso commented Jun 3, 2022

I'm not sure why this hasn't merged. @rvanasa are you not allowed to merge, even with approval, or were you holding back for #3282 instead?

@ggreif
Copy link
Contributor

ggreif commented Jun 3, 2022

@rvanasa if you cannot merge, try adding the automerge-squash label. If that also fails then we are happy to push the button for you!

@rvanasa
Copy link
Contributor Author

rvanasa commented Jun 3, 2022

@ggreif it looks like I would need write permissions to add a label to the PR. Thanks for merging when you get the chance!

@ggreif ggreif added the automerge-squash When ready, merge (using squash) label Jun 3, 2022
@mergify mergify bot merged commit 4067378 into dfinity:master Jun 3, 2022
@mergify mergify bot removed the automerge-squash When ready, merge (using squash) label Jun 3, 2022
@crusso
Copy link
Contributor

crusso commented Jun 4, 2022

Fab! Thanks again!

mergify bot pushed a commit that referenced this pull request Jun 4, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Buggy behaviour with go to definition
5 participants