This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Add modernize-increment-bool check.
Needs RevisionPublic

Authored by mnbvmar on Apr 15 2016, 9:47 AM.

Details

Diff Detail

Event Timeline

mnbvmar updated this revision to Diff 53907.Apr 15 2016, 9:47 AM
mnbvmar retitled this revision from to [clang-tidy] Add modernize-increment-bool check..
mnbvmar updated this object.
mnbvmar added reviewers: alexfh, Prazek, staronj, krystyna.
mnbvmar added a subscriber: cfe-commits.

This strikes me as something the compiler should diagnose instead of a clang-tidy check. Incrementing a bool has been deprecated for some time, but it is outright removed in C++17, so I think giving users a migration path as part of the compiler would be far more beneficial. What do you think?

Prazek edited edge metadata.Apr 15 2016, 3:46 PM

This strikes me as something the compiler should diagnose instead of a clang-tidy check. Incrementing a bool has been deprecated for some time, but it is outright removed in C++17, so I think giving users a migration path as part of the compiler would be far more beneficial. What do you think?

clang already warns about it, but I don't think it has good fixits.

Besides comments, looks good to me. But before posting make sure that clang-diagnostics doesn't already have fixits.

clang-tidy/modernize/IncrementBoolCheck.cpp
51

doesn't isInTemplateInstantiation fix it?

clang-tidy/modernize/ModernizeTidyModule.cpp
38

run git-clang-format on your patch, because I see that perhaps this one and other files coud be clang-formatted

docs/clang-tidy/checks/modernize-increment-bool.rst
50–55

put this one under the if statment and remove comments liek this:

if (!first)

second = first++;

// is equivalent to

if (!first) {
    second = false;
    first = true;
  }
alexfh edited edge metadata.Apr 15 2016, 6:25 PM

This strikes me as something the compiler should diagnose instead of a clang-tidy check. Incrementing a bool has been deprecated for some time, but it is outright removed in C++17, so I think giving users a migration path as part of the compiler would be far more beneficial. What do you think?

clang already warns about it, but I don't think it has good fixits.

What clang diagnostic flags this issue? I'd rather make sure it provides good fixits than as a clang-tidy check that does almost the same. Clang-tidy can be configured to run Clang diagnostics and it will happily apply fixes if asked to.

alexfh requested changes to this revision.Apr 15 2016, 6:26 PM
alexfh edited edge metadata.
This revision now requires changes to proceed.Apr 15 2016, 6:26 PM

This strikes me as something the compiler should diagnose instead of a clang-tidy check. Incrementing a bool has been deprecated for some time, but it is outright removed in C++17, so I think giving users a migration path as part of the compiler would be far more beneficial. What do you think?

clang already warns about it, but I don't think it has good fixits.

What clang diagnostic flags this issue? I'd rather make sure it provides good fixits than as a clang-tidy check that does almost the same. Clang-tidy can be configured to run Clang diagnostics and it will happily apply fixes if asked to.

-Wdeprecated-increment-bool does it. But what I see from SemaExpr.cpp in CheckIncrementDecrementOperand, it doesn't have any fixits.

Prazek added a comment.May 3 2016, 7:05 AM

ping @alexfh have you check it?

mnbvmar updated this revision to Diff 58940.May 30 2016, 2:32 AM
mnbvmar edited edge metadata.

Clang-formatted code.
Added a simple macro test.
Resolved @Prazek's issues.

ping @alexfh have you check it?

I would still strongly prefer to see this fixed in CheckIncrementDecrementOperand instead of creating an entire clang-tidy check for it.

alexfh requested changes to this revision.Jun 3 2016, 4:06 PM
alexfh edited edge metadata.

-Wdeprecated-increment-bool does it. But what I see from SemaExpr.cpp in CheckIncrementDecrementOperand, it doesn't have any fixits.

If an automated fix for this issue makes sense at all, it should be implemented in the Clang's diagnostic. BTW, have you seen this pattern in the real code? I haven't. Maybe it's so rare that implementing a fix-it suggestion for it just isn't worth the effort?

This revision now requires changes to proceed.Jun 3 2016, 4:06 PM