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

x/tools/gopls: consider adding special cases for main Go tree and modules when linkifying issues #46245

dmitshur opened this issue May 18, 2021 · 3 comments
FeatureRequest gopls NeedsInvestigation Tools


Copy link

@dmitshur dmitshur commented May 18, 2021

@heschi pointed out to me that gopls has a feature of turning text like org/repo#123 into links to corresponding GitHub issues.

The main Go repository and most (if not all) modules use the main Go issue tracker ( and have many¹ existing comments that refer to Go issues as just "#​123" or "issue 123".

If it's deemed okay to add special cases to that behavior for the Go project itself, this is a feature request to adjust the linkifying behavior of gopls to recognize when the module path is something in the standard library (just std, cmd would go a long way) or has a prefix, and not require the "golang/go" prefix. That would help make existing comments useful and reduce the desire to be adding the otherwise-not-strictly-needed "golang/go" prefix in Go comments.

¹ (Details)

A quick grep in the Go tree at commit a2c07a9:

"see issue \d+"  - 286 matches
"see issue #\d+" - 143 matches
"see #\d+"       - 82 matches
"golang/go#\d+"  - 5 matches

CC @stamblerre, @heschi.

@dmitshur dmitshur added NeedsInvestigation FeatureRequest gopls Tools labels May 18, 2021
@gopherbot gopherbot added this to the Unreleased milestone May 18, 2021
Copy link

@findleyr findleyr commented May 19, 2021

If we're going to do this, couldn't we equally well add support for any module path that is a subpath of<user>/<repo> (i.e. resolve #123 to<user>/<repo>/issues/123)?

Of course we'd still need special handling for modules.

Copy link
Contributor Author

@dmitshur dmitshur commented May 19, 2021

Yes, I think that would be possible too, although there may be some edge cases that couldn't be handled easily. For example, GitHub forks, or repositories with custom module paths (module whose source code lives on

If considering GitHub, might want to also consider other common code hosting sites that cmd/go already knows about and their issue trackers. Of course such work would be larger and should be tracked in separate issue(s), so this one can be remain about just the Go project.

@stamblerre stamblerre removed this from the Unreleased milestone May 19, 2021
@stamblerre stamblerre added this to the gopls/unplanned milestone May 19, 2021
Copy link

@heschi heschi commented May 19, 2021

We could consider keying off of codereview.cfg as a (theoretically) less special case than import paths, but AFAIK literally nobody else uses git-codereview.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
FeatureRequest gopls NeedsInvestigation Tools
None yet

No branches or pull requests

5 participants