When the import resolver walks GOPATH for possible packages to import, it does not follow symbolic links. This causes issues during automatic code generation when the host environment was not set up for a Go workflow and the generator itself is emulating a Go workspace via symbolic links.

Although some threads mention that Go tools do not like symbolic links, the x/tools/loader seems perfectly happy to load the packages from symlinked paths, so there's an inconsistency in what one tool accepts and another doesn't.

The issue is at two places in the code:

• https://github.com/golang/tools/blob/master/imports/fix.go#L213
• https://github.com/golang/tools/blob/master/imports/fix.go#L254

where only real subfolders are followed, but not symlinks.

A simple solution is to add || child.Mode()&os.ModeSymlink == os.ModeSymlink, but that could lead to circular symlinks (which is probably the reason why it wasn't implemented in the first place). However that should be solvable by maintaining a list of physical paths already seen ad ignoring the symlink if it couples back to such a path.