This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy][NFC] Update tests and Default options to use boolean value
ClosedPublic

Authored by njames93 on May 2 2021, 5:25 AM.

Details

Summary

Change instances where options which are boolean are assigned the value 1|0 to use true|false instead.

Diff Detail

Event Timeline

njames93 created this revision.May 2 2021, 5:25 AM
njames93 requested review of this revision.May 2 2021, 5:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 2 2021, 5:25 AM
aaron.ballman accepted this revision.May 3 2021, 4:17 AM

LGTM! One thing I'd like to be sure of though -- do we still have at least one test that's showing you can use false/0 and true/1/nonzero interchangeably? If not, we should probably have one that shows which "alternate forms" are accepted.

This revision is now accepted and ready to land.May 3 2021, 4:17 AM

LGTM! One thing I'd like to be sure of though -- do we still have at least one test that's showing you can use false/0 and true/1/nonzero interchangeably? If not, we should probably have one that shows which "alternate forms" are accepted.

clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp::CheckOptionsValidation::ValidIntOptions contains a test which supports 0 and 1.
However in a few years once we can be confident most users are using clang-tidy-11 or newer, it may be wise to drop support for 0 and 1 in order to be inline with yaml completely.

LGTM! One thing I'd like to be sure of though -- do we still have at least one test that's showing you can use false/0 and true/1/nonzero interchangeably? If not, we should probably have one that shows which "alternate forms" are accepted.

clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp::CheckOptionsValidation::ValidIntOptions contains a test which supports 0 and 1.

Awesome, thank you for verifying!

However in a few years once we can be confident most users are using clang-tidy-11 or newer, it may be wise to drop support for 0 and 1 in order to be inline with yaml completely.

I think if we want to go that route (which seems sensible to me), we should start warning on using anything but true/false as being deprecated. WDYT?

However in a few years once we can be confident most users are using clang-tidy-11 or newer, it may be wise to drop support for 0 and 1 in order to be inline with yaml completely.

I think if we want to go that route (which seems sensible to me), we should start warning on using anything but true/false as being deprecated. WDYT?

That's sort of the plan, however we shouldn't make that change right away as there's no point in issuing warnings at this time. As configurations are checked in there is likely to be people still using 10 and previous, which don't support the new spelling. This means the config can't be updated and users with newer clang-tidy versions will get a warning they can't silence.

However in a few years once we can be confident most users are using clang-tidy-11 or newer, it may be wise to drop support for 0 and 1 in order to be inline with yaml completely.

I think if we want to go that route (which seems sensible to me), we should start warning on using anything but true/false as being deprecated. WDYT?

That's sort of the plan, however we shouldn't make that change right away as there's no point in issuing warnings at this time. As configurations are checked in there is likely to be people still using 10 and previous, which don't support the new spelling. This means the config can't be updated and users with newer clang-tidy versions will get a warning they can't silence.

That makes sense to me. Should we file a bug to suggest adding the deprecation warning in Clang 14(?) and planned removal in Clang 16(?) so that we don't lose track of this? (I have no firm opinion about which versions we decide to start deprecating and remove so long as they're not disruptive.)

That makes sense to me. Should we file a bug to suggest adding the deprecation warning in Clang 14(?) and planned removal in Clang 16(?) so that we don't lose track of this? (I have no firm opinion about which versions we decide to start deprecating and remove so long as they're not disruptive.)

I was thinking later tbh. clang-tidy 11 is where the spelling support was adopted and, more importantly, emitting a warning when a present key could not be parsed. Giving 3 years from there puts a deprecation notice in Clang17 (Assuming we stick to the same semiannual release cycle).