Skip to content
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

cmd/vet: inconsistent exit value #4980

Closed
dsymonds opened this issue Mar 5, 2013 · 3 comments

Comments

Projects
None yet
4 participants
@dsymonds
Copy link
Member

commented Mar 5, 2013

If there's a printf format specifier error, govet exits with status 1. If there's a
struct field tag incompatible with reflect.StructTag.Get, govet exits with 0. The other
vet checks do a mix of those. It should be made consistent so other tooling can depend
on it.
@robpike

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2013

Comment 1:

Can you be more specific? There is one that should be fixed (Printf(os.Stderr) gives
only a warning) but the only other Warnf call in print.go is a type-checking failure
that is unlikely unless go/types failed on the package. In that case the diagnosis is
really only a warning.
There are a few Warnf calls in other modules that should be made Badf but you explicitly
called out print checking.
@dsymonds

This comment has been minimized.

Copy link
Member Author

commented Mar 5, 2013

Comment 2:

I called out print checking, not because it's necessarily wrong, but because I noticed
it was different to some others. Is it your intention that govet should exit with 1 if
there are problems it finds? That sounds okay to me, but (1) it should be documented,
and (2) the few warnings that don't use Badf should be fixed. It just wasn't clear to me
what the exit value semantics were supposed to be.
@robpike

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2013

Comment 3:

This issue was closed by revision 8cf6e75.

Status changed to Fixed.

@dsymonds dsymonds added fixed labels Mar 5, 2013

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015

@rsc rsc removed the go1.1 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.