Skip to content

[NFC][CodingStandard] Require[[maybe_unused]] for unused variables in asserts #142850

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

Merged
merged 3 commits into from
Jun 25, 2025

Conversation

jurahul
Copy link
Contributor

@jurahul jurahul commented Jun 4, 2025

Require using attribute [[maybe_unused] for assert-only variables that may be unused in non-assert enabled builds to suppress unused variable warnings.

@jurahul jurahul force-pushed the deprecate_void_cast branch from c62a5f8 to b62488c Compare June 4, 2025 20:47
@jurahul jurahul marked this pull request as ready for review June 4, 2025 20:52
@jurahul jurahul requested review from AaronBallman, bogner and nikic June 4, 2025 20:52
@fmayer
Copy link
Contributor

fmayer commented Jun 4, 2025

Just confirming that this means something like

void f(int x) {
#ifdef XYZ
  (void)x;
  [...]
#else
  [do something with x]

becomes

void f([[maybe_unused]] int x) {
#ifdef XYZ
  [...]
#else
  [do something with x]

@jurahul
Copy link
Contributor Author

jurahul commented Jun 4, 2025

Just confirming that this means something like

void f(int x) {
#ifdef XYZ
  (void)x;
  [...]
#else
  [do something with x]

becomes

void f([[maybe_unused]] int x) {
#ifdef XYZ
  [...]
#else
  [do something with x]

Yes. The attribute is needed only in function definition and not in the declaration.

@fmayer
Copy link
Contributor

fmayer commented Jun 4, 2025

Yes. The attribute is needed only in function definition and not in the declaration.

My point being that we lose some precision about where it is unused, but that we think that is ok.

@jurahul
Copy link
Contributor Author

jurahul commented Jun 4, 2025

I see your point. If due to a bug it became unused in the #else path the prior code would still warn, the new one would not. I'll let the reviewers decide if this loss of precision is fine. If we really need to preserve this precision while still using maybe_unused it seems we could do something like:

void f(int x) {
#ifdef XYZ
  [[maybe_unused]] int dummy = x;
#else
  // use x;
#endif
}      

@jurahul jurahul requested a review from jh7370 June 5, 2025 13:49
@chrisjbris
Copy link
Contributor

Is it worth mentioning that [[maybe_unused]] is also applicable to functions too, not just variables?

@jurahul jurahul force-pushed the deprecate_void_cast branch 4 times, most recently from 433d4c7 to 6777de1 Compare June 18, 2025 22:20
@jurahul jurahul requested a review from chrisjbris June 18, 2025 22:21
@jurahul jurahul changed the title [NFC][CodingStandard] Deprecate use of void casts to suppress warnings [NFC][CodingStandard] Prefer use of [[maybe_unused]] over C-style void cast for unused variables Jun 18, 2025
@jurahul jurahul changed the title [NFC][CodingStandard] Prefer use of [[maybe_unused]] over C-style void cast for unused variables [NFC][CodingStandard] Prefer [[maybe_unused]] over C-style void cast for unused variables Jun 19, 2025
* Although ``[[maybe_unused]]`` is preferred to suppress warnings about unused
variables in simple cases (for example, variables used only in asserts) casting
to ``void`` using a C-style cast can also be used to suppress such warnings if
using ``[[maybe_unused]]`` is not acceptable.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This doesn't clearly explain when [[maybe_unused]] is not acceptable, so it isn't really a useful standard, in my opinion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, this was an attempt to keep the complex cases (per the discourse discussion) unspecified. Maybe we can just say that for variables uses solely in asserts, you must use [[maybe_unused]] and remove the simple cases language. That is say:

  • To suppress unused variable warnings for variables used solely in asserts, use [[maybe_unused]].
  • For other cases, either [[maybe_unused]] or C-style void cast is acceptable.

Copy link
Collaborator

Choose a reason for hiding this comment

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

That's an improvement, certainly, though I should add that I'm an "always [[maybe_unused]] proponent, since it more clearly expresses intent to those not as experienced with programming in general.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, but based on the forum discussion, not everyone is on board with that. I have amended the PR now with the above changes. The delta now is essentially that for variables used only in asserts, we require the use of maybe_unused over C-style casts. I am hoping that will be an acceptable delta.

@jurahul jurahul requested a review from jh7370 June 19, 2025 12:09
@jurahul jurahul force-pushed the deprecate_void_cast branch from 6777de1 to 355dac7 Compare June 20, 2025 15:39
Recommend using attribute `[[maybe_unused]`` for variables that
may be unused in non-assert enabled builds to suppress unused variable
warnings.
@jurahul jurahul force-pushed the deprecate_void_cast branch from 355dac7 to 9d78736 Compare June 20, 2025 15:40
@jurahul jurahul changed the title [NFC][CodingStandard] Prefer [[maybe_unused]] over C-style void cast for unused variables [NFC][CodingStandard] Require[[maybe_unused]] over C-style void cast for unused variables Jun 21, 2025
@jurahul jurahul changed the title [NFC][CodingStandard] Require[[maybe_unused]] over C-style void cast for unused variables [NFC][CodingStandard] Require[[maybe_unused]] over C-style void cast for unused variables in asserts Jun 21, 2025
@jurahul jurahul changed the title [NFC][CodingStandard] Require[[maybe_unused]] over C-style void cast for unused variables in asserts [NFC][CodingStandard] Require[[maybe_unused]] for unused variables in asserts Jun 21, 2025
Copy link
Collaborator

@jh7370 jh7370 left a comment

Choose a reason for hiding this comment

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

I'm happy with this, but please wait for others.

Copy link
Contributor

@nikic nikic left a comment

Choose a reason for hiding this comment

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

I'm ok with it.

@jurahul
Copy link
Contributor Author

jurahul commented Jun 23, 2025

Thanks. Will wait for other folks to review as well.

Copy link
Contributor

@chrisjbris chrisjbris left a comment

Choose a reason for hiding this comment

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

lgtm

@jurahul
Copy link
Contributor Author

jurahul commented Jun 24, 2025

Thanks. @nikic and/or @AaronBallman if one of you can approve as well, I will go ahead and merge it. Thanks!

@jurahul jurahul requested a review from nikic June 24, 2025 17:39
Copy link
Collaborator

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

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

LGTM!

@jurahul jurahul merged commit 00f6d6a into llvm:main Jun 25, 2025
8 checks passed
@jurahul jurahul deleted the deprecate_void_cast branch June 25, 2025 22:47
anthonyhatran pushed a commit to anthonyhatran/llvm-project that referenced this pull request Jun 26, 2025
…s in asserts (llvm#142850)

Require using attribute `[[maybe_unused]` for assert-only variables that
may be unused in non-assert enabled builds to suppress unused variable
warnings.

---------

Co-authored-by: James Henderson <[email protected]>
Co-authored-by: Nikita Popov <[email protected]>
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.

6 participants