Open H0llyW00dzZ opened 2 weeks ago
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
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.
this broken
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 foo bar
. The bug report shows a more realistic case where the pathological path segment is the operating system's own Program Files
directory, which leaks into package paths when gopls synthesizes command-line-arguments
packages.
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 Program Files
problem; genuine (pathological) package paths such as my foo bar
example may contain spaces (or other arbitrary syntax such as close paren).
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: gopls/internal/golang: fix hovering from the builtin file
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