Issue Type: Feature Request
it would be nice to see if a function is referenced in the code or not. click on the codelens and see all the places the variable, function being referenced.
variable:
functions:
Extension version: 2020.8.1301 VS Code version: Code - Insiders 1.49.0-insider (bd08768fd310d34cdd4423a53e5f3ca77340fea5, 2020-08-14T05:56:40.601Z) OS version: Windows_NT x64 10.0.18363
Comment From: stamblerre
I believe that this feature is supported in GOPATH mode, but is not yet available via the language server. I have been hesitant to add it, since users should just be able to call "Find References" on a symbol to get this information. I would be curious to hear input from others before we move forward with this.
Comment From: sanket-bhalerao
@stamblerre, i tried following for the GOPATH mode.
- set GOPATH to current working directory
- install all the tools required for the extension
- my settings for go are
i still dont see the codelens. am i missing something?
Comment From: hyangah
The codelens is off by default, so you will need to turn it on explicitly.
"go.enableCodeLens": {
"references": true,
}
But, if you are using the language server, why not use the Find References feature which is faster and doesn't add much visual noise to the code.
Comment From: sanket-bhalerao
@hyangah , thanks for the help
as to why not use find reference, i work mainly with angular and now just habituated with the codelens. i feel more comfortable with it i guess
Comment From: hyangah
@sanket-bhalerao Is your goal to simply check whether the variable or function is used or not (boolean decision), or you use it to really find all the locations they are used? For former, I think we can do better with color or other visualization than with codelens. For latter, maybe we should discuss more.
Comment From: sanket-bhalerao
@hyangah for variables its the boolean decision (as golang shows unused var as errors this part is already covered) for functions and methods I use it for find if it is referenced at alss and all the places its used.
Comment From: hyangah
@sanket-bhalerao Thanks! I will transfer this to gopls issue tracker.
Comment From: stamblerre
Thanks for the feature request, @sanket-bhalerao. I'd like to hear from others about the benefits of this feature. Currently, my preference would be to add the 'unused' checks from staticcheck (https://github.com/golang/go/issues/36602), which might make this feature a little redundant.
Comment From: TerminalFi
references is a quick insight into how many times a function is being called an generally would allow the end click to create a view into where the functions / etc are being used for quick looks. I think this is much more valuable than what is being shown here. And completely different from staticcheck. Just look at elm language server for instance
Comment From: stamblerre
references is a quick insight into how many times a function is being called an generally would allow the end click to create a view into where the functions / etc are being used for quick looks. I think this is much more valuable than what is being shown here. And completely different from staticcheck. Just look at elm language server for instance
This feature is already available by right-clicking an identifier and selecting "Find all references". The code lens would make it easy to tell if a symbol is referenced, which is typically used to see if it is used anywhere in the workspace--much like the staticcheck 'unused' check.
Comment From: TerminalFi
I guess a workaround to get this feature would just have the client implementation make the request automatically rather than having to click and request them. 🤷♂️ Seems like it may be more of a personal preference thing at that point ?
Comment From: stamblerre
I think we would be open to this feature being added in gopls, but it would have to be off by default, because it would be expensive to constantly call "find references" on every symbol in a given file. Still, we will not prioritize work on this, so if a community member would like to pick this up and send a CL, please follow up here.
Comment From: tooltitude-support
We implemented this feature in our extension, tooltitude. We focus on augmenting gopls with convenience and productivity features. For example on screenshot you could see the usages of Join in the "stirngs" on kubernetes repo. It computed all reference counts in around 500ms on my M1 Max Macbook pro. On smaller files, and projects it's much faster. On machines with more cores the perf is even better.
P.S. You could read more about it here: https://www.tooltitude.com/ You could install from here: https://marketplace.visualstudio.com/items?itemName=tooltitudeteam.tooltitude
cc @TerminalFi @stamblerre @hyangah @sanket-bhalerao
P.S. Updated check time value to reflect a fix of a bug.
Comment From: TerminalFi
Looks cool! I am a ST User, and maintain LSP-gopls. I see this is closed source. That is too bad
Comment From: tooltitude-support
@TerminalFi In theory nothing prevents it working from within ST. It's mostly LSP, with some additional requests and notifications to improve integration with VSCode. At some point we will consider it, taking into account that sublime is closed source too and people happily pay for performance (i.e. they are more likely than vscode users to be interested in commercial extension).
Comment From: tkgalk
@TerminalFi I have a VS Code extension that is open-source here: https://github.com/tkg-codes/go-interface-annotations. I have also mentioned this in https://github.com/golang/go/issues/56695 unfortunately there doesn't seem to be any movement on this one. :(
I moved to neovim since making that extension for VSCode and it seems I can't get the same thing working on nvim, which is really, really sad.
Comment From: TerminalFi
@TerminalFi I have a VS Code extension that is open-source here: https://github.com/tkg-codes/go-interface-annotations. I have also mentioned this in https://github.com/golang/go/issues/56695 unfortunately there doesn't seem to be any movement on this one. :(
I moved to neovim since making that extension for VSCode and it seems I can't get the same thing working on nvim, which is really, really sad.
Time to move to Sublime ;)
Comment From: tkgalk
Does it work there? Goddamit. Do you know if gopls even supports this? I can make the neovim extension, but I need to know whether gopls can even return textdocument/references or textdocument/implementations correctly...
Unless I can get something like in GoLand or in VSCode, I'm going to keep baning my head against the wall and trying to recreate it in neovim. :D
Comment From: TerminalFi
I am working on an update to LSP-gopls
Comment From: tkgalk
Hm, are you getting this data from gopls? 🤔 If so then it should be possible for me to code it for neovim too.
Comment From: TerminalFi
Hm, are you getting this data from
gopls? 🤔 If so then it should be possible for me to code it for neovim too.
Yes. Essentially this is the logic I am using.
- File is activitated (Opened or Focused)
- Send LSP Request
textDocument/documentSymbol - For each Symbol returned
for symbol in symbols:
params = {
'textDocument': {'uri': view_to_uri(self.view)},
'position': symbol['selectionRange']['start']
}
request = Request("textDocument/references", params)
Comment From: tkgalk
Hm, this is what I tried. Hm. Maybe I just messed something up the last time. Oh well, got a new weekend project, I guess. Cheers!
Comment From: TerminalFi
@tkgalk I actually have a working implementation in a branch of gopls. I need to figure out the proper way to open an MR for it though.
Seems to be relatively fast
@stamblerre I might need a little direction on handling sending the response back to the client. Looks like i need to do something in tsclient.go
Comment From: tkgalk
Yeah, I managed to code something for neovim, I'll release it later on GitHub for anyone wanting to use it, but I need to finish some stuff first (filter out declarations, add configuration options and squash a bug or two).
Thanks for pointing me in the right direction. :D
While making it, I also found that someone had already done something similar, though: https://github.com/VidocqH/lsp-lens.nvim.
Comment From: TerminalFi
Yeah, just meant that this should be in core once I finish this. So it won't need to be handled by the client.
Comment From: FOWind
We implemented this feature in our extension, tooltitude. We focus on augmenting gopls with convenience and productivity features. For example on screenshot you could see the usages of Join in the "stirngs" on kubernetes repo. It computed all reference counts in around 500ms on my M1 Max Macbook pro. On smaller files, and projects it's much faster. On machines with more cores the perf is even better.
P.S. You could read more about it here: https://www.tooltitude.com/ You could install from here: https://marketplace.visualstudio.com/items?itemName=tooltitudeteam.tooltitude
cc @TerminalFi @stamblerre @hyangah @sanket-bhalerao
P.S. Updated check time value to reflect a fix of a bug.
Nice extensions !!!
Comment From: 0DAYBROKER
Any news on this matter?
Comment From: vec715
any updates on this?
Comment From: vec715
We implemented this feature in our extension, tooltitude. We focus on augmenting gopls with convenience and productivity features. For example on screenshot you could see the usages of Join in the "stirngs" on kubernetes repo. It computed all reference counts in around 500ms on my M1 Max Macbook pro. On smaller files, and projects it's much faster. On machines with more cores the perf is even better.
P.S. You could read more about it here: https://www.tooltitude.com/ You could install from here: https://marketplace.visualstudio.com/items?itemName=tooltitudeteam.tooltitude cc @TerminalFi @stamblerre @hyangah @sanket-bhalerao P.S. Updated check time value to reflect a fix of a bug.
Nice extensions !!!
No, this is a paid extension with pretty mature price ( I think getting JB Goland will be a cheaper option lol), afwul that we does not have such a basic functionality with default vscode extension
Comment From: tkgalk
No, this is a paid extension with pretty mature price ( I think getting JB Goland will be a cheaper option lol), afwul that we does not have such a basic functionality with default vscode extension
To be fair to Tooltitude, I think that specific part of the reference count is free.
https://github.com/tkgalk/go-interface-annotations you can take a look at my extension that does this. It is implemented in a fairly naive way, though, so in big codebases or large files it might be slow, but I haven't tested it thoroughly as I don't use VS Code anymore. But yes, it is a shame, that this isn't part of the gopls itself.
Comment From: vec715
No, this is a paid extension with pretty mature price ( I think getting JB Goland will be a cheaper option lol), afwul that we does not have such a basic functionality with default vscode extension
To be fair to Tooltitude, I think that specific part of the reference count is free.
https://github.com/tkgalk/go-interface-annotations you can take a look at my extension that does this. It is implemented in a fairly naive way, though, so in big codebases or large files it might be slow, but I haven't tested it thoroughly as I don't use VS Code anymore. But yes, it is a shame, that this isn't part of the gopls itself.
looks awesome! thank you, definitely will try it
Comment From: adonovan
Gopls supports the ability to find all references to a symbol, globally ("Go to References" in VS Code). It also shows when an unexported package-level function or declared method is unreferenced and may be safely deleted.
I think there is more we could do; for example, we could - show when an unexported package-level type, constant, or variable is unused (https://go.dev/cl/681336); - show a one-time report of which symbols (including exported ones) are globally unreferenced throughout the workspace; - run the the deadcode command on a given module and show its results.
(Each of these should be a different feature request.)
However, accurate global information cannot be efficiently computed in real-time, which is what a code lens demands. Also, the code lens feature of LSP is poorly supported in many clients and we've been trying to reduce our use of it.
So I would like to close this issue.
Comment From: tkgalk
However, accurate global information cannot be efficiently computed in real-time
Great to see that other IDEs (GoLand comes to mind) managed to solve the impossible. :P
Comment From: gopherbot
Change https://go.dev/cl/681336 mentions this issue: gopls/internal/analysis/unusedfunc: support var, type, func
Comment From: findleyr
@tkgalk in seriousness, Goland is not limited by the LSP, and therefore (for example) doesn't have to bundle these code lenses with others. Sometimes things that should be easy are hard, because we're limited by the protocol.
I interpret @adonovan's point as "if a references code lens must be 100% accurate and lumped in with all other code lenses, then it necessarily requires blocking a file-local request on a global workspace type checking pass, and we aren't going to do that".
However, I will point out that "code lens refresh" could enable us to use (potentially stale) indexes for reference count. We could theoretically use inaccurate heuristics to compute this code lens, and refresh if ever the reindexed data differed from the stale data. https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens_refresh
But that's a significant bit of complexity for (in our opinion) marginal gain, and so it's unlikely to get prioritized in the near future.
Comment From: tkgalk
I know, I'm being an ass. I do think this is possible under the LSP protocol, as I don't believe there is anything stopping gopls to keep it's own local index and responding from that according to LSP calls. But I might be missing something very obvious. It is a very strong GoLand feature that many of us really hoped to see be enabled by gopls.