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

Introduce GIT_WARN_UNUSED_RESULT #5802

Merged
merged 8 commits into from
Aug 25, 2021

Conversation

lhchavez
Copy link
Contributor

@lhchavez lhchavez commented Feb 17, 2021

This change adds the GIT_WARN_UNUSED_RESULT annotation, which makes the
compiler warn when a return result is not used. This avoids bugs.

@lhchavez lhchavez force-pushed the git-warn-unused-result branch 2 times, most recently from 33ff48d to 67998a8 Compare February 23, 2021 01:11
@ethomson
Copy link
Member

Naive question - is there an attribute for the inverse of this - where we accept that it's okay that the return value is unused?

I think that for most of our codebase, we should enforce checking return codes. I can only think of a few outliers (like the buf functions, where we accept that an OOM situation will eventually get checked, but we might chain several functions together before we do that check).

I have no idea how bad -Wunused-result would actually be, and it looks like it has some pain points of its own, I'm just curious.

@lhchavez
Copy link
Contributor Author

Naive question - is there an attribute for the inverse of this - where we accept that it's okay that the return value is unused?

not as a standard attribute :( the closest thing would be a custom clang-tidy check. i personally wouldn't be opposed to investigating how to get one working, but it's probably better to start with an allow-list of functions we know we want to keep using their return values always plus possibly another macro to mark the ignoring of a return value as acceptable (i.e. this change), and once the whole codebase is clean, we can switch it around.

I think that for most of our codebase, we should enforce checking return codes. I can only think of a few outliers (like the buf functions, where we accept that an OOM situation will eventually get checked, but we might chain several functions together before we do that check).

I have no idea how bad -Wunused-result would actually be, and it looks like it has some pain points of its own, I'm just curious.

we're already using -Wunused-result! that's what powers the warnings for functions annotated with GIT_WARN_UNUSED: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says:

-Wno-unused-result
Do not warn if a caller of a function marked with attribute warn_unused_result (see Function Attributes) does not use its return value. The default is -Wunused-result.

@lhchavez
Copy link
Contributor Author

Naive question - is there an attribute for the inverse of this - where we accept that it's okay that the return value is unused?

not as a standard attribute :( the closest thing would be a custom clang-tidy check. i personally wouldn't be opposed to investigating how to get one working, but it's probably better to start with an allow-list of functions we know we want to keep using their return values always plus possibly another macro to mark the ignoring of a return value as acceptable (i.e. this change), and once the whole codebase is clean, we can switch it around.

I think that for most of our codebase, we should enforce checking return codes. I can only think of a few outliers (like the buf functions, where we accept that an OOM situation will eventually get checked, but we might chain several functions together before we do that check).
I have no idea how bad -Wunused-result would actually be, and it looks like it has some pain points of its own, I'm just curious.

btw tweaking GIT_UNUSED() to 4ebb573#diff-07a0ff24f834c533d980cd176412c1cf4777562a3a10fe49ae049e06adff4487R46 eliminates most of the pain points. it uses a gcc-ism, but then again the GIT_WARN_UNUSED macro also does.

we're already using -Wunused-result! that's what powers the warnings for functions annotated with GIT_WARN_UNUSED: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says:

-Wno-unused-result
Do not warn if a caller of a function marked with attribute warn_unused_result (see Function Attributes) does not use its return value. The default is -Wunused-result.

@ethomson
Copy link
Member

we're already using -Wunused-result! that's what powers the warnings for functions annotated with GIT_WARN_UNUSED: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says:

Ohhhh, I didn't fully understand the interaction here. This makes sense. Thanks for the explanation.


/* Unlock sorted cache when done with read */
void git_sortedcache_runlock(git_sortedcache *sc);

/* Lookup item by key - returns NULL if not found */
void *git_sortedcache_lookup(const git_sortedcache *sc, const char *key);
GIT_WARN_UNUSED_RESULT void *git_sortedcache_lookup(
Copy link
Member

Choose a reason for hiding this comment

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

I like GIT_WARN_UNUSED_RESULT for things that return errors that really must be paid attention to, for example things that allocate. I'm less bullish on things like this. One on hand, I think that I understand the motivation: why are you calling this function if you don't care about the result? It's side effect free. So its only purpose in life is to compute a result for you. Calling it and ignoring the result is just a waste of cycles.

🤔

I feel like we should draw up some simple guidelines about where and when we use GIT_WARN_UNUSED_RESULT... It feels like you're proposing a place where we land on it almost always. Is that roughly accurate?

Copy link
Contributor Author

@lhchavez lhchavez Mar 4, 2021

Choose a reason for hiding this comment

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

i could also be okay with restricting its use to only places that allocate or grab a mutex (that case is also pretty scary).

if/when another clang-tidy solution exists where everything is checked except for a few allow-listed functions, things'll be less verbose and we'll get better coverage.

@ethomson
Copy link
Member

Sorry for the long delay. One last question: does this need to be in the public api? I’d rather keep this defined in some header in src/

@lhchavez
Copy link
Contributor Author

Sorry for the long delay. One last question: does this need to be in the public api? I’d rather keep this defined in some header in src/

it doesn't need to, let me move it!

@lhchavez
Copy link
Contributor Author

Sorry for the long delay. One last question: does this need to be in the public api? I’d rather keep this defined in some header in src/

it doesn't need to, let me move it!

welp, not sure what happened, but now the MSVC builds are not picking the macro up :/

@lhchavez lhchavez force-pushed the git-warn-unused-result branch 2 times, most recently from 999262b to d63ce35 Compare July 30, 2021 14:32
This change adds the GIT_WARN_UNUSED_RESULT annotation, which makes the
compiler warn when a return result is not used. This avoids bugs.
This adds a `-Wunused-result`-proof `GIT_UNUSED()`, just to demonstrate
that it works. With this, sortedcache.h is now completely
`GIT_WARN_UNUSED_RESULT`-annotated!
Now we're limiting ourselves to only functions that allocate or acquire
locks.
Previously, the location of `GIT_WARN_UNUSED_RESULT` was causing it to
be included _after_ a bunch of other headers (namely `src/vector.h`),
which broke the build.

This change does two things:

* Moves the `GIT_WARN_UNUSED_RESULT` above most of the `$include`s in
  `src/common.h`.
* Stops including `vector.h` from `src/win32/path_w32.c` since the
  header itself does not use it.
@lhchavez lhchavez force-pushed the git-warn-unused-result branch 2 times, most recently from bd08c29 to 991ccdc Compare August 9, 2021 02:24
@ethomson
Copy link
Member

This is really nice. Thanks.

@ethomson ethomson merged commit efc4e7e into libgit2:main Aug 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants