-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: -coverpkg documentation is too oblique about import paths #69653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Documentation
Issues describing a change to documentation.
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
Change https://go.dev/cl/616257 mentions this issue: |
matttproud
added a commit
to matttproud/go
that referenced
this issue
Sep 27, 2024
This change amends the long-form help output for 'go help build' and 'go help testflag' to specify that the '-coverpkg' flag operates explicitly on import paths as well as package names. Import paths are fundamental for precise specification of packages versus unqualified package names, and the naming of the flag '-coverpkg' and its original documentation leads a user to assume that it only operates on the simple, unqualified package name form. The situation warrants clarification. Fixes golang#69653
matttproud
added a commit
to matttproud/go
that referenced
this issue
Sep 28, 2024
This change amends the long-form help output for 'go help build' and 'go help testflag' to specify that the '-coverpkg' flag operates explicitly on import paths as well as package names. Import paths are fundamental for precise specification of packages versus unqualified package names, and the naming of the flag '-coverpkg' and its original documentation leads a user to assume that it only operates on the simple, unqualified package name form. The situation warrants clarification. Fixes golang#69653
matttproud
added a commit
to matttproud/go
that referenced
this issue
Oct 3, 2024
This change amends the long-form help output for 'go help build' and 'go help testflag' to specify that the '-coverpkg' flag operates explicitly on import paths as well as package names. Import paths are fundamental for precise specification of packages versus unqualified package names, and the naming of the flag '-coverpkg' and its original documentation leads a user to assume that it only operates on the simple, unqualified package name form. The situation warrants clarification. Fixes golang#69653
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Documentation
Issues describing a change to documentation.
NeedsFix
The path to resolution is known, but the work has not been done.
Go version
go version go1.23-20240626-RC01 cl/646990413 +5a18e79687 X:fieldtrack,boringcrypto linux/amd64
Output of
go env
in your module/workspace:What did you do?
I ran
go help testflag
andgo help build
to understand how to adjust the code coverage package specification parameters to ensure certain packages were included or excluded from code coverage analysis.What did you see happen?
go help testflag
emitted a fragment similar to this:go help build
emitted a fragment similar to this:What did you expect to see?
The text as written for both
-coverpkg
flags mentions the word "package" in a rather oblique way such that a casual reader of the text would infer the meaning of "package" to refer to a package name and not the import path, when in truth the pattern used by both of these flags also can select packages based on import paths.I had wanted specialized coverage analysis based on several import paths and not simple package names (unqualified) for a development task I was doing, and I found the current documentation as written confusing in this regard. The external documentation referred to with "go help packages" helps to be sure, but a quick read of the original help output for these flags would erroneously lead a reader to assume that import paths are not supported.
I would like to propose the verbiage is changed to include mention of import paths. There are several ways this can be done. I have put together a small proposal in a changelist that I'll submit shortly.
The text was updated successfully, but these errors were encountered: