Nested modules in general are rare enough that I would be fine with a special-case to avoid this lookup.

I seem to remember a recent issue from @myitcv, where he reported that the go tool was incorrectly trying to find a myitcv.io module.

On the other hand, if we get rid of the finding chatter (#26152), is it actually that harmful to search for other modules? Those lookups should complete quickly anyway.

@mvdan the example I had was actually with github.com in #33351

Should we do the same for “child” modules? (If you import rsc.io/tmp/x/foo instead of rsc.io/tmp/x/boo, should we try to resolve the module rsc.io/tmp/x/boo?)

If not, why is it more important to suppress the parent lookup than the child?

I had a difficult Sunday trying to figure out why go build suddenly stopped working for me, and @bcmills was kind enough to point me here, once I could explain well enough what went on. Several problems came together to blind me to the cause.

I've been writing a Go module on my computer, but I have not committed any of the source to a remote Git repository yet. It's committed locally, but I haven't pushed it elsewhere.

At one point I created a package within this module, and I wrote an import statement to import that package into another package. Then I decided to delete that first package; I deleted the directory, but I neglected to remove the import statement from the other package that was depending on it.

At this point, when I would run go build, it would hang indefinitely, with no output. Running go build -v showed that it was trying to fetch this missing package first from the public Go proxy, and then via HTTP, then with the git tool over SSH. Since my machine lacked the proper Git configuration to allow go get to authenticate properly against the remote Git repository (it needs a particular user name for use with SSH), go get couldn't get Git to authenticate. It would retry several times, and then just hang.

All of this surprised me. I had assumed that if I'm editing files within a dominating module file, then the Go tools would trust that all of the pertinent code is here on my own disk. Even with my errant package import statement referring to a nonexistent package below the module path, I still didn't expect the Go tools to think that package would be available "out there." I expected my own disk content to be the source of truth.

@seh, could you open a separate issue for the hang? Even if we do an unnecessary lookup, it's supposed to complete quickly.

Please see #35209.