x/tools/cmd/godoc: incorrect href link for dot import

[gopherbot]

by fgmarand:

What does 'go version' print?
  go version go1.3 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. unpack the archive in src/
2. start godoc -http=:6060
3. go to http://localhost:6060/pkg/outer/inner
4. examine the link to OuterA within InnerA

What happened?

  The link points to http://localhost:6060/pkg/outer/inner/#OuterA

What should have happened instead?

  The link should have pointed to http://localhost:6060/pkg/outer/#OuterA

Additional information

  This appears to be because of the default import alias: when using a normal import, even aliased (like: import o "outer"), the link is built correctly.

Attachments:

1. outer.tgz (10240 bytes)

[ianlancetaylor]

Comment 1:

Labels changed: added repo-tools, release-none.

[agnivade]

I looked into this. The issue seems to be that when an type is referred from a dot imported package, the underlying ast.Ident does not seem to have the import information.

But in case the type is qualified with a package, then the ast.SelectorExpr has 2 ast.Idents. One for the qualifier, one for the type. And the qualifier ident has it's .Obj field populated with the ast.ImportSpec from where the package path is retrieved.

So, in the case for dot imports the package path information is non-existent.

@griesemer - Do you see this as a fix to go/doc to denote whether a type is dot-imported or not, and if so add the importspec ? There is already a conversion happening from doc.namedType to doc.Type.

[griesemer]

@agnivade In general, w/o complete type information (or at the very least, import data), when we see an identifier that cannot be found in any scope we don't know if it's declaration is missing (due to a missing file), or whether it might be dot-imported (and which dot-import if there are several in the same file). I don't know that we can fix this in go/doc easily w/o processing imports somehow.