-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: space in package path leads to invalid hover markdown #68026
Comments
Similar Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
I did not test this on windows but I was unable to reproduce it on Linux. Perhaps the space in the url is causing the markdown to not be rendered. If so seems to be a vscode-go issue. Either way, these pkg.go.dev urls mixed with the local Go toolchain path will result in a 404. Edit: I was wrong, gopls formats the markdown links https://github.com/golang/tools/blob/019da39/gopls/internal/golang/hover.go#L1156. We should probably escape urls here. cc @hyangah |
Yes, the other one is correct. |
Thanks for trying the prerelease, and for the report. We will investigate. Assigning to @adonovan, who has been working in this area. |
As @mauri870 points out, the problem is indeed that if the package path has a space in it, the markdown is invalid. It's trivial to reproduce this by creating a package in a directory with a pathological name such as Still thinking about a fix. |
One possibility is to emit angle brackets around the link. Compare these two, while looking at the markdown source:
But that requires adjusting every place in gopls that puts package paths in markdown links, which is potentially a lot; and it's an unfamiliar syntax. It also seems like a hard invariant to maintain. Another approach is to URL-encode the URLs, since spaces aren't really safe. But it also seems like a hard invariant to maintain since we're so used to not thinking about URL encoding in markdown. A third approach is to choose paths that don't contain spaces when synthesizing packages. But that only solves the Option 2 seems best to me. |
Thanks. This isn't a regression then, moving out of the v0.16.0 milestone (that should have been obvious to me -- sorry for missing it in my haste). |
So, to summarize, there are two bugs here:
(1) should be fixed by a relatively straighforward application of url escaping. Assigning to our new team member @h9jiang as this is a good starter exercise for bug fixing and writing a test. On the other hand, (2) might require a more sweeping refactoring of how we handle the builtin file and unsafe packages, and is just about the polar opposite of a good starter bug: requires familiarity with nitty-gritty details of the codebase. I will do this part. |
Change https://go.dev/cl/594795 mentions this issue: |
The builtin file represents a psuedo package for builtin documentation. When hovering over a builtin declared in the builtin file, its corresponding hover content should be the same as hovering at the call site. Fix this by intercepting hover requests originating from the builtin file. Along the way, fix a bug that jumping to a definition in the builtin file went to the declaring node, not declaring identifier. For golang/go#68026 Change-Id: I070ec701cb7e067dd1cbb14a968c063169bb541c Reviewed-on: https://go-review.googlesource.com/c/tools/+/594795 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Findley <rfindley@google.com>
gopls version
go env
What did you do?
Reference documentation is broken
What did you see happen?
Today
What did you expect to see?
The link to the reference documentation is broken. It should be:
builtin.IntegerType on pkg.go.dev
Editor and settings
No response
Logs
No response
The text was updated successfully, but these errors were encountered: