Go: x/tools/godoc: godoc failing on aliases when viewing pkg/builtin

Created on 25 Aug 2017  路  13Comments  路  Source: golang/go

This is not really an issue with the language but with golang.org

What did you do?

Visited https://golang.org/pkg/builtin/

What did you expect to see?

The doc

What did you see instead?

A build error

2017-08-24_17 35 02_crop_screenshot

FrozenDueToAge

Most helpful comment

I'm not really sure what to do here, other than move from GAE standard to GAE flexible (or GKE), where we'd have more control over that.

I strongly believe we need to move off GAE standard. We need control of the Go version going forward. We will by definition always be ahead of App Engine, and using GAE standard precludes us from ever using new Go features in godoc. This will just keep biting us. We should move to Flex or GKE.

All 13 comments

I can reproduce this even locally and interestingly godoc at https://golang.org says it is running on Go1.9
screen shot 2017-08-24 at 9 50 56 pm

where the failing code in question is
screen shot 2017-08-24 at 9 52 22 pm

/cc @broady @griesemer @adams-sarah

Works for me running x/tools/cmd/godoc locally.

Seems like the golang.org godoc is built weird. Maybe it's a mix of versions. (one version godoc, one version GOROOT?).

@odeke-em, what do you mean by you can "reproduce this even locally". You can make it fail? I can't. It works for me: http://gdev.bradfitz.com:6060/pkg/builtin/#byte

Good proposition @bradfitz actually that seems plausible, now I just re-ran go get golang.org/x/tools/cmd/godoc and now it works alright locally. Perhaps we need to do the exact same thing on production.

CC @griesemer @broady

golang.org should be running on the 1.9 release branch for tools. Looking at this bug, though, it probably isn't. Wither I made a mistake when deploying, or the 1.9 release branch for tools is missing something from master. Former is more likely.

looks good on tip.golang.org: https://tip.golang.org/pkg/builtin/

Oh, it's because GAE is on Go <1.9. godoc uses the standard library.

I'm not really sure what to do here, other than move from GAE standard to GAE flexible (or GKE), where we'd have more control over that.

Are there other instances of broken pages, or just builtin?

Maybe a short term fix is a monkey patch to make the content of the builtin page static.

edit: ok, looks like the only type aliases in the standard library are for rune and and byte.

It's not very correct, but we could apply this patch (basically, going back to 1.8) just for golang.org. That is:

@@ -85,11 +85,11 @@ type uintptr uintptr
 // byte is an alias for uint8 and is equivalent to uint8 in all ways. It is
 // used, by convention, to distinguish byte values from 8-bit unsigned
 // integer values.
-type byte = uint8
+type byte byte

 // rune is an alias for int32 and is equivalent to int32 in all ways. It is
 // used, by convention, to distinguish character values from integer values.
-type rune = int32
+type rune rune

The built-in package is a fake package anyway and only here for documentation. It seems fine to me to go back to 1.8 with that file for godoc only. Maybe:

type byte uint8 // really: type byte = uint8, but alias declarations are not supported in 1.8

Could be unrelated, but godoc.org doesn't appear to be returning results as before.

The search https://godoc.org/?q=os doesn't return the os package itself.

Affected packages:

strings

Ditto for strings - I'll now amend my previous comment with other packages that suffer the same problem

@myitcv, can you open a separate ticket at github.com/golang/gddo?

I'm not really sure what to do here, other than move from GAE standard to GAE flexible (or GKE), where we'd have more control over that.

I strongly believe we need to move off GAE standard. We need control of the Go version going forward. We will by definition always be ahead of App Engine, and using GAE standard precludes us from ever using new Go features in godoc. This will just keep biting us. We should move to Flex or GKE.

Was this page helpful?
0 / 5 - 0 ratings