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.

@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?

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.

@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

@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.

@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.

@sanket-bhalerao Thanks! I will transfer this to gopls issue tracker.

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 (#36602), which might make this feature a little redundant.

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

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.

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 ?

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.

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.

Looks cool! I am a ST User, and maintain LSP-gopls. I see this is closed source. That is too bad

@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).

@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 #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.

@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 #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 ;)

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

I am working on an update to LSP-gopls

Hm, are you getting this data from gopls? 🤔 If so then it should be possible for me to code it for neovim too.

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.

1. File is activitated (Opened or Focused)
2. Send LSP Request textDocument/documentSymbol
3. 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)

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!

@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

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.

Yeah, just meant that this should be in core once I finish this. So it won't need to be handled by the client.

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 !!!