-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
fix: prefer non-export definition locations #20252
Conversation
.filter(_.source == sym.source) | ||
.partition(_.tree.symbol.is(Exported)) | ||
|
||
otherDefs.headOption.orElse(exportedDefs.headOption) match |
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.
What if instead of returning the head option we returned all the locations, in that List(loc)
below, so that then downstream can show users a choice of location (i.e. the source of the export and the original)?
Other than that lgtm
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.
Generally, that makes sense. However, for this particular case it will cause an inconsistency in Metals. If the definition and user's cursor are not in the same file, pc will use Metals's symbol search, and that search will not be able to find the export <smth>.*
. So I am not sure that it would be better.
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.
Other than that lgtm
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! We can switch to showing export location also if needed, but that is more complex, since semanticdb doesn't contain the symbols within the file with exports
Backports #20252 to the LTS branch. PR submitted by the release tooling. [skip ci]
fixes: scalameta/metals#5892