Skip to content

Conversation

@cameron-martin
Copy link
Contributor

@cameron-martin cameron-martin commented Dec 20, 2023

When executing "go to definition" on a label, it would previously go to the correct file but not to the definition of that target. This was because we were searching for a function call where the name is the whole label. Now it parses the label, using the label parser introduced in #101, to extract the name and searches using that.

When executing "go to definition" on a label, it would previously go to the correct file but not to the definition of that target. The reason was because we were searching for a function call where the name is the whole label. Now it parses the label to extract the name and searches using that.

This doesn't work in a few cases, for example "//foo" and "@foo", where the name is implicit. However, I think to solve this we would need to implement a label parser. If one already exists, I could not find it. I imagine a lot of the code in `resolve_folder` could be simplified with the use of a label parser too.
@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Dec 20, 2023
@stagnation
Copy link

stagnation commented Dec 20, 2023

Nice! Works well for local targets for me :) and handles @ for the root, did not get it to go to external repositories, or the main repo with its full name. But that sounds out-of-scope for this improvement.

@cameron-martin
Copy link
Contributor Author

That's strange. It works for going to external repositories for me, just not when in a file in an external repository.

@stagnation
Copy link

Good! My bad, I had the runfiles library as the abbreviated package-only label. With runfiles:runfiles it does work!

cameron-martin added a commit to cameron-martin/starlark-rust that referenced this pull request Dec 20, 2023
Instead of parsing labels ad-hoc in `resolve_folder`, this introduces a separate label parser. This allows re-using this when doing a "go to definition" for a label that is not in a load statement. See facebook#100 for more context.
@cameron-martin
Copy link
Contributor Author

With #101 I will be able to fix this problem

cameron-martin added a commit to cameron-martin/starlark-rust that referenced this pull request Jan 2, 2024
Instead of parsing labels ad-hoc in `resolve_folder`, this introduces a separate label parser. This allows re-using this when doing a "go to definition" for a label that is not in a load statement. See facebook#100 for more context.
@cameron-martin cameron-martin marked this pull request as draft January 3, 2024 10:41
facebook-github-bot pushed a commit that referenced this pull request Jan 19, 2024
Summary:
Instead of parsing labels ad-hoc in `resolve_folder`, this introduces a separate label parser. This allows re-using this when doing a "go to definition" for a label that is not in a load statement. See #100 for more context.

Pull Request resolved: #101

Reviewed By: stepancheg

Differential Revision: D52887102

Pulled By: ndmitchell

fbshipit-source-id: e08c07b3d88c24d14030568dcc3ecf33ae8c243c
facebook-github-bot pushed a commit to facebook/buck2 that referenced this pull request Jan 19, 2024
Summary:
Instead of parsing labels ad-hoc in `resolve_folder`, this introduces a separate label parser. This allows re-using this when doing a "go to definition" for a label that is not in a load statement. See facebook/starlark-rust#100 for more context.

X-link: facebook/starlark-rust#101

Reviewed By: stepancheg

Differential Revision: D52887102

Pulled By: ndmitchell

fbshipit-source-id: e08c07b3d88c24d14030568dcc3ecf33ae8c243c
@ndmitchell
Copy link
Contributor

Any reason not to undraft this?

@cameron-martin
Copy link
Contributor Author

Any reason not to undraft this?

Yep I was waiting for the label parser to go in so I could use it here. I'll update this soon and undraft it.

@cameron-martin cameron-martin marked this pull request as ready for review January 19, 2024 20:42
@cameron-martin
Copy link
Contributor Author

@ndmitchell This should be now good to go!

@facebook-github-bot
Copy link
Contributor

@ndmitchell has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

facebook-github-bot pushed a commit to facebook/buck2 that referenced this pull request Jan 22, 2024
Summary:
When executing "go to definition" on a label, it would previously go to the correct file but not to the definition of that target. This was because we were searching for a function call where the name is the whole label. Now it parses the label, using the label parser introduced in facebook/starlark-rust#101, to extract the name and searches using that.

X-link: facebook/starlark-rust#100

Reviewed By: wendy728

Differential Revision: D52954185

Pulled By: ndmitchell

fbshipit-source-id: 937da257b7441d8abe313015ca1c8241c7967a10
@facebook-github-bot
Copy link
Contributor

@ndmitchell merged this pull request in 1f2fe80.

@cameron-martin cameron-martin deleted the fix-bazel-lsp-go-to-label branch January 22, 2024 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants