New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gopherbot opened this Issue Jul 20, 2014 · 3 comments

Comments

Projects
None yet
6 participants
@gopherbot

gopherbot commented Jul 20, 2014

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

This comment has been minimized.

Contributor

ianlancetaylor commented Jul 20, 2014

Comment 1:

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

@gopherbot gopherbot added new labels Jul 20, 2014

@bradfitz bradfitz removed the new label Dec 18, 2014

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed the release-none label Apr 10, 2015

@rsc rsc changed the title from cmd/godoc: incorrect href link for dot import to x/tools/cmd/godoc: incorrect href link for dot import Apr 14, 2015

@rsc rsc removed the repo-tools label Apr 14, 2015

@agnivade

This comment has been minimized.

Member

agnivade commented May 1, 2018

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

This comment has been minimized.

Contributor

griesemer commented May 1, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment