godef: no declaration found for (symbol) when package name != containing directory name

[colonelpanic8]

No description provided.

[zippoxer]

+1

Is it idiomatic to walk through the import paths and visit some go file in each package to get it's name?

[tbg]

I looked into this and it requires a lot of familiarity with how AST parsing/resolution works. With a little guidance, maybe this can be picked up. What I tried naively was to walk through pkg.Imports and seek out any Decl[i].(_GenDecl).Specs[j].(_ImportSpec).Name == nil (in which case we want to load the package given under <same>.Path). I have no idea whether that's the right thing to do. It seems too manual, like there should be a resolver tool that does this already.

[colonelpanic8]

I think that the problem is with ImportPathToName

godef/go/parser/parser.go

Line 26 in f90a996

func ImportPathToName(p string) string {

This thing should really be going into the path specified in the import and figuring out what the name of the package contained in that path is.

[colonelpanic8]

@tschottdorf I fixed this. Give the version from my pull request a try and see if it works for you.

[colonelpanic8]

Is it idiomatic to walk through the import paths and visit some go file in each package to get it's name?

I feel like there should be.

@rogpeppe this solution feels pretty hacky/gross, which is why I didn't really bother to clean it up much in my PR. Let me know if you would be willing to accept something like this -- If so I'll clean it up and write a test or two.

[colonelpanic8]

Also @rogpeppe why does godef seem to have its own version of the go parser/ast code?

[colonelpanic8]

It looks like #3 was another (much simpler) attempt to solve this issue. What happened to that PR.

[rogpeppe]

godef has its own version of the go parser code because when it was written,
I hoped that the changes (that resolve almost all symbols at parse time)
might make it upstream. They didn't, but the fork lives on.

The reason for this bug is essentially that I wanted godef to be fast, so it takes
a shortcut which makes it wrong some of the time. That was probably not
the best decision, but it's quite a hassle to change, and probably not
worth the effort now that guru is almost there.

For the record, the speed is gained because godef resolves
all symbols without actually pulling in the import packages, so
when searching for a local symbol, it only needs to read the
local package's files. This is wrong in two cases: when an imported
package uses a different symbol from its directory name, and
when using "import .".

[colonelpanic8]

@rogpeppe godef is still plenty fast with this change though. I set the only parse package mode so it should really just open ONE file in the package and read what the package is. I refuse to believe that that has enough of a performance impact to make this change unviable. At the very least, I'd like to see profiling that indicates that it has too large an effect.

Premature optimization is the root of all evil.

[colonelpanic8]

@rogpeppe I hand't heard of go guru before. I just got it set up and it seems to work really well. What is merely 'almost there' about it?

[rogpeppe]

Fixed by #34