Currently, if you ask go doc for an exported identifier, and it happens to be declared as a var or const with the type inferred from the initializer, the type of the variable does not appear in the output.
It is doubly frustrating if the initializer happens to refer to unexported identifiers, since go doc requires an extra flag before it will document those (#33133).
What version of Go are you using (go version)?
~/go/src$ go version
go version devel +87bf0b5c51 Tue Jul 16 13:17:46 2019 -0400 linux/amd64
What did you do?
~/go/src$ go doc go/build.ToolDir
What did you expect to see?
The documentation for and type of the go/build.ToolDir variable.
What did you see instead?
~/go/src$ go doc go/build.ToolDir
package build // import "go/build"
var ToolDir = getToolDir()
ToolDir is the directory containing build tools.
No indication of whether ToolDir is a string, a []byte, or something else entirely. It isn't mentioned in the doc comment, and it shouldn't need to be mentioned in the doc comment because the compiler already knows what it is.
Currently, if you ask
go docfor an exported identifier, and it happens to be declared as avarorconstwith the type inferred from the initializer, the type of the variable does not appear in the output.It is doubly frustrating if the initializer happens to refer to unexported identifiers, since
go docrequires an extra flag before it will document those (#33133).What version of Go are you using (
go version)?What did you do?
What did you expect to see?
The documentation for and type of the
go/build.ToolDirvariable.What did you see instead?
No indication of whether ToolDir is a
string, a[]byte, or something else entirely. It isn't mentioned in the doc comment, and it shouldn't need to be mentioned in the doc comment because the compiler already knows what it is.