Update golangci-lint to v1.56.1
#2714
Conversation
dhrubabasu
requested review from
danlaine,
darioush,
dboehm-avalabs,
abi87,
gyuho,
marun,
joshua-kim,
StephenButtolph and
ceyonur
as code owners
dhrubabasu
changed the title
golangci-lint to v1.56.0golangci-lint to v1.56.1
| @@ -300,13 +300,13 @@ func (vtx *uniqueVertex) String() string { | |||
| len(txs), | |||
| )) | |||
|
|
|||
| parentFormat := fmt.Sprintf("\n Parent[%s]: ID = %%s, Status = %%s", | |||
| parentFormat := fmt.Sprintf("\n Parent[%s]: ID = %%s, Status = %%s", //nolint:perfsprint | |||
There was a problem hiding this comment.
why are we disabling linting here? There were other places where we were able to replace Sprintf with simpler alternative. What's the difference here?
There was a problem hiding this comment.
I tried changing it a few times but the code got more confusing. We don't stringify the unique vertex enough to sacrifice code clarity for performance IMO
| keys := make([]*secp256k1.PrivateKey, 5) | ||
| for i := range keys { | ||
| key, err := secp256k1.NewPrivateKey() | ||
| require.NoError(err) | ||
| require.NoError(t, err) |
There was a problem hiding this comment.
why? Is there a linter complaining about this?
There was a problem hiding this comment.
When we use require, we should use it with the most scoped t variable. Further down this test, we do require := require.New(t) in the sub-test. The linter was complaining that the sub-test t *testing.T was unused.
| @@ -21,7 +21,7 @@ type noOpTracer struct { | |||
| } | |||
|
|
|||
| func (n noOpTracer) Start(ctx context.Context, spanName string, opts ...trace.SpanStartOption) (context.Context, trace.Span) { | |||
| return n.t.Start(ctx, spanName, opts...) | |||
| return n.t.Start(ctx, spanName, opts...) //nolint:spancheck | |||
There was a problem hiding this comment.
the linter suggests there is a possible memory leak here. Should we end the spam right away for the noop tracer instead of silencing the linter?
NoOpTracer does not seem to be used in prod code currently but I think it's best to avoid any possible memory leak, even in UTs
There was a problem hiding this comment.
The consumer should be ending the span. The linter is complaining that the returned span is unassigned so there could be a possible memory leak
dhrubabasu
force-pushed
the
golangci-lint-version-56-0
branch
from
638d385
to
013f4b1
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to no response for status checks
Why this should be merged
Linters 🧹
How this works
gciand removesgoimportsspanchecktestifylintand removes some of our bash lintersunused-parameterto check anonymous functions mgechev/revive#965 (filed by @StephenButtolph ;))How this was tested
CI