-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
go1.7 vet flags "possible formatting directive" when Error is used #339
Comments
@prashantv this will require creating methods like Let me look into it :) |
ernesto-jimenez
added a commit
that referenced
this issue
Sep 24, 2016
@prashantv what does #356 look like? |
ernesto-jimenez
added a commit
that referenced
this issue
Sep 25, 2016
Thanks @ernesto-jimenez, left some comments but overall looks good! |
prashantv
added a commit
to uber/tchannel-go
that referenced
this issue
Oct 4, 2016
We can't lint on 1.7 till we work around stretchr/testify#339
prashantv
added a commit
to uber/tchannel-go
that referenced
this issue
Oct 4, 2016
We can't lint on 1.7 till we work around stretchr/testify#339
prashantv
added a commit
to uber/tchannel-go
that referenced
this issue
Dec 21, 2016
We can't lint on 1.7 till we work around stretchr/testify#339
ernesto-jimenez
added a commit
that referenced
this issue
May 29, 2017
ghost
pushed a commit
to hyperledger/fabric-ca
that referenced
this issue
Oct 9, 2017
Updated github.com/stretchr/testify package to the latest version to fix the problem described in the issue stretchr/testify#339 Change-Id: Ib030abdb5e435448e97966c4a6c3dd8bd4a6b9fd Signed-off-by: Anil Ambati <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the
assert.Error
method is used with formatting arguments, go vet complains as of 1.7:For more information and a repro, see:
uber-go/zap#135
The specific check that is run is here:
https://golang.org/src/cmd/vet/print.go#L587
I'm not sure if there's a good fix for this, but I wanted to flag this, as I typically:
assert.Error
callsassert.Error
instead ofassert.NotNil
However, this "correct" usage of the library leading to a vet failure may mean users will either avoid one or the other.
The text was updated successfully, but these errors were encountered: