cmd/go: generate ./... is defeated by submodules #58723
Labels
Comments
|
Change https://go.dev/cl/471115 mentions this issue: |
|
Duplicate of #56098 |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Mar 1, 2023
This change establishes that "go generate ./..." from within the gopls directory will update all generated code in the module to its canonical version. (Beware that this command doesn't work in the parent directory due to golang/go#58723.) Details: - The main 'generate' command now includes the canonical git ref name of the LSP protocol used by gopls, and by default it clones the repo at this version instead of using the version in pjw's home directory. ;-) It should deliver identical results for all users without setup. The "generated" comment includes an accurate URL. The timestamp is removed since it is nondeterministic. - In addition to the commit hash, the output now reports the git ref (branch/tag) name, which is not the same as the metadata.version (LSP protocol version) string. - The go:generate comments are now more prominent in their respective files. We hide several that appear in testdata from the go command by splitting string literals. - Improved command documentation for generators. - Use a slice not map for genTypes so that protocol generation is deterministic. (Previously the "created for" comments would alternate between TextDocumentFilter_Item{0,1}.) The generated output has changed trivially ("//x" -> "// x") because the most recent committed generated files was stale wrt recent generator changes. Also, line number comments now start at 1, not zero (eliminating a TODO). Change-Id: I40e9454d0042507bd64e0d8fab3ce6b1fbe87ddc Reviewed-on: https://go-review.googlesource.com/c/tools/+/471115 Run-TryBot: Alan Donovan <adonovan@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Peter Weinberger <pjw@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The session below shows a repo containing a root module and a submodule, and a go.work file that uses both. The command
go generate ./...within the submodule directory causes generators to run, but the commandgo generate ./sub/...from the root directory does nothing---this despitego list ./sub/...reporting the packages of the submodule.I think this is a bug and that
go generate ./sub/...should cause generators to run on all files of all directories of the packages that would be enumerated bygo list ./sub/....The text was updated successfully, but these errors were encountered: