x/tools/godoc: support linking to interface methods

[bradfitz]

We can already link to struct fields, as of a few releases ago:

https://golang.org/pkg/net/http/#Server.IdleTimeout

But we can't link to interface methods:

https://golang.org/pkg/net/http/#ResponseWriter.WriteHeader

[dsnet]

My work on #18342 in (CL/72890) actually resolves this issue.

E.g., http.ResponseWriter.WriteHeader

[bradfitz]

@dsnet, I haven't been following godoc since I got back. Is that slated for this release?

[dsnet]

No. It will probably be for Go1.11.

[ugorji]

Any chance we can get this in for go 1.10? It would be really nice to get this in sooner than later. I reckon that this change can go in, as it doesn't affect running programs, but it makes a useful tool much better. Waiting for go 1.11 means waiting until August/Sept 2018 - a very long time away.

[mvdan]

@ugorji 1.10 is only five weeks away, so this is already the last stage of bugfixing. New features are very unlikely to be merged this late.

It's also worth pointing out that godoc (as part of golang.org/x/...) is not distributed with Go. I'm not sure why the Go1.11 milestone was used, as opposed to the Unreleased one. Perhaps that's related to what will run on godoc.org, as opposed to what will be available via go get.

[ugorji]

@mvdan exactly my point. Since this is not distributed with go, then can we possibly get this in sooner than August/Sept 2018? It feels like we're almost there - and there's no train saying we have to wait for 8/9 months.

[dsnet]

That is not true. The go, gofmt, and godoc binaries are distributed with each release, effectively pulling in part of the x repo into the release cycle.

[navytux]

And now the story continues of not getting this in into Go 1.11 . Or am I wrong?

[mvdan]

For the record, hotlinking is now being tracked at #25444.

@navytux I would suggest getting involved if you would like this to happen faster. For example, I believe that the latest development is this CL, which seems to be looking for more input: https://go-review.googlesource.com/c/tools/+/72890

[mvdan]

I think this is now fixed - both links from Brad's original post now work perfectly fine :) It might have happened as part of the transition into https://pkg.go.dev. Closing for now, but @golang/pkgsite please reopen if I got this wrong.

[dsnet]

Hahaha, the saga continues: #62293.

[kolyshkin]

I think this is now fixed - both links from Brad's original post now work perfectly fine :) It might have happened as part of the transition into https://pkg.go.dev. Closing for now, but @golang/pkgsite please reopen if I got this wrong.

@mvdan while it is fixed in pkg.go.dev, it's not fixed in x/tools/godoc for some reason.

Here's a quick repro, using the very latest x/tools v0.25.0, tagged two weeks ago.

$ go install golang.org/x/tools/cmd/godoc@latest
go: downloading golang.org/x/tools v0.25.0
$ godoc -url pkg/net/http/ | grep ResponseWriter.WriteHeader
    <span class="comment">// [ResponseWriter.WriteHeader]. The [Header] map also is the mechanism with which</span>
    <span class="comment">// Changing the header map after a call to [ResponseWriter.WriteHeader] (or</span>
    <span class="comment">// If [ResponseWriter.WriteHeader] has not yet been called, Write calls</span>

As you can see, id="ResponseWriter.WriteHeader" is not present. OTOH if you use pkg.go.dev, it's there:

$ curl -s https://pkg.go.dev/net/http | grep ResponseWriter.WriteHeader
</span>	<span class="comment">// [ResponseWriter.WriteHeader]. The [Header] map also is the mechanism with which</span>
	<span class="comment">// Changing the header map after a call to [ResponseWriter.WriteHeader] (or</span>
	<span class="comment">// If [ResponseWriter.WriteHeader] has not yet been called, Write calls</span>
<span id="ResponseWriter.WriteHeader" data-kind="method">	<span class="comment">// WriteHeader sends an HTTP response header with the provided</span>

Since this bug is about x/tools/godoc, and not pkg.go.dev, I think this should be reopened, or a new bug filed.

[seankhliao]

see #59056 godoc won't see any more development