(@adonovan found a reference citing a 32kb limit, which appears to be exceeded by the collective set of package directories in that test output).
Shortening our test module path resolved the failure (for now), but I expect we'll hit it again soon as we add more test data. Furthermore, our test data is certainly smaller than even medium-sized repositories, so it seems likely that our users are hitting this limit in practice.
Ideally, go/packages.Load should handle these limitations within the go list driver, perhaps by breaking up large queries.
While moving internal/lsp to gopls/internal/lsp, we discovered that
we're bumping up against a command line length limit on windows. Use an
arbitrary shorter module path to avoid this, for now.
Run-TryBot: Robert Findley <email@example.com>
TryBot-Result: Gopher Robot <firstname.lastname@example.org>
Reviewed-by: Alan Donovan <email@example.com>
gopls-CI: kokoro <firstname.lastname@example.org>
On second thought, I doubt this is feasible. While tools like gopls necessarily have to deal with the go command seeing a different version of the filesystem, it must be an invariant that the view of the filesystem observed by go list is consistent.
changed the title
x/tools/go/packages: handle os-specific command length limitationsSep 8, 2022