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

Add nilness lint pass and fix its findings #61608

Merged
merged 6 commits into from
Mar 18, 2021

Conversation

stevendanna
Copy link
Collaborator

@stevendanna stevendanna commented Mar 8, 2021

This adds a nilness lint pass that checks for errant uses of provably nil values.

This nilness analyzer was taken from golang.org/x/tools and then modified
to add checks for various errors.Wrapf-style functions where passing a nil value
can lead to a nil error to be returned when the author likely expected a non-nil error.

While most of the errors fixed here were found by the nilness linter's check for
"degenerate" if conditions, I've turned off that check for now as there are still some cases
to fix.

Release note: None

@stevendanna stevendanna requested review from a team as code owners March 8, 2021 13:47
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@stevendanna stevendanna force-pushed the ssd/nilness branch 2 times, most recently from 5b2e981 to 54e98e1 Compare March 8, 2021 16:10
@@ -436,6 +436,8 @@ func (j *jsonEncoded) FetchValKey(key string) (JSON, error) {
}
return string(data) >= key
})
// TODO(ssd): This err will always be nil. It looks
// like we intended to assign to it at 433 above.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this was added in #21676 and I agree it looks like the function passed to sort.Search is suppose to set the outer err variable.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've pushed a fix that collects the last non-nil error. I'm mildly nervous since from what I can see the unit test suite doesn't hit many of the error paths in this code. But I'm made less nervous by the fact that (I believe) an error here would imply that the caller has some incorrectly encoded json and this code already assumes a correct encoding in a number of places.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@stevendanna stevendanna force-pushed the ssd/nilness branch 2 times, most recently from 34c21ef to 3998829 Compare March 9, 2021 11:19
@stevendanna stevendanna requested review from a team and miretskiy and removed request for a team March 17, 2021 11:45
@knz
Copy link
Contributor

knz commented Mar 17, 2021

👏 👏 👏 👏 💯

This imports the nilness check from golang.org/x/tools at commit
3e1cb95235af786c5d1f0deffbd0b0646bf00024 with minor modifications to
pass our linter.

The purpose of importing this linter into the source tree rather than
depending on it is so that we can make local modifications to it in
future commits.

Release note: None
These functions return nil if the first argument provided is nil.
While this behaviour is often useful, passing an always-nil value to
such a function is typically an indication of a bug.

Release note: None
The "degenerate" cases that the nilness pass found covered a number of
cases where the "tautological" check made the code a bit more readable
or cases where a nil check might be tautological now, but could easily
change in the future.

Release note: None
These calls to errors.Wrap-style functions were passing errors that
would always be nil, which means that they would be returning a nil
error rather than the non-nil error that the author likely expected.

Release note: None
These cases were found by the nilness linter. Most appear to be err
checks that were simply copy and pasted but were no longer needed.

Release note: None
The nilness linter checks for errant uses of provably nil values. The
most useful of these checks so far as been its ability to find
errors.Wrapf-style functions that are always being passed nil errors.

Release note: None
@stevendanna
Copy link
Collaborator Author

bors r=miretskiy

@craig
Copy link
Contributor

craig bot commented Mar 18, 2021

Build succeeded:

@craig craig bot merged commit fc2f2c3 into cockroachdb:master Mar 18, 2021
@knz
Copy link
Contributor

knz commented May 25, 2021

I think this should be back ported to at least 20.2 where we are still fixing bugs.

craig bot pushed a commit that referenced this pull request May 25, 2021
65656: server: simplify an error case r=stevendanna a=knz

Found while re-reviewing #61608

cc @cockroachdb/server for education

`NewAssertionErrorWithWrappedErrf` already includes the text of the
original error on the right of the wrapping message. No need to
include it a second time.

Release note: None

Co-authored-by: Raphael 'kena' Poss <knz@thaumogen.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants