Add bugprone-bool-to-integer-conversion

[Prazek]

Summary

Tested on llvm codebase.
It have found many places like:

• returning true/false in function returning int,
• assigning true/false to integer inside some classes.

[Prazek]

Maybe we should merge it with http://reviews.llvm.org/D18745 and name it 'modernize-wrong-literal-cast'. The other question is, will it be better to move it to readability?

[krystyna]

docs/clang-tidy/checks/modernize-bool-to-integer-conversion.rst

9 ↗

(On Diff #52776)

int a = false;

[mnbvmar]

This check throws a warning also on the conversion to floats (probably very rare ones):

double number = true;

Even though this behavior is correct, the code warns about the implicit conversion to integers.

docs/ReleaseNotes.rst

193

with int literals

[Prazek]

In D18821#393556, @mnbvmar wrote:

This check throws a warning also on the conversion to floats (probably very rare ones):

double number = true;

Even though this behavior is correct, the code warns about the implicit conversion to integers.

That case is extremaly rare. I will see what I can do

[Prazek]

Added new test cases

[alexfh]

Actually, did you think about adding this as a clang diagnostic?

Richard, what do you think about complaining in Clang about int i = true; kind of code?

clang-tidy/modernize/BoolToIntegerConversionCheck.cpp

49 ↗

(On Diff #52855)

s/. Use/; use/

Same below.

docs/ReleaseNotes.rst

193

The phrase is technically incorrect. The check does not replace implicit cast from bool literals. It replaces bool literals (which are being implicitly cast to integers) with integer literals.

docs/clang-tidy/checks/modernize-bool-to-integer-conversion.rst

9 ↗

(On Diff #52855)

There should be an empty line after .. code-block ....

[Prazek]

In D18821#394486, @alexfh wrote:

Actually, did you think about adding this as a clang diagnostic?

Richard, what do you think about complaining in Clang about int i = true; kind of code?

Glad to hear that :)

[alexfh]

clang-tidy/modernize/BoolToIntegerConversionCheck.cpp

47 ↗

(On Diff #52855)

I'd prefer an alternative with less code duplication:

auto Diag = diag("implicitly converting bool literal to %0%select{|inside a macro}1; use ...") << Type;
if (<should add fixes>)
  Diag << 1 << FixItHint::...;
else
  Diag << 0;

[Prazek]

Used isMacroID to determinate if it's macro

[alexfh]

BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.

I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.

clang-tidy/modernize/BoolToIntegerConversionCheck.cpp

43 ↗

(On Diff #53114)

nit: Since both positive and negative branches are present, I'd prefer to make the condition slightly simple by removing the negation.

[Prazek]

In D18821#398843, @alexfh wrote:

BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.

I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.

There were many places. Most of them where when assigning true/false to some member which was int.
The other place was inside some functions that were returning only true or false, but the return type of this function was int, so I guess what programmer meant there was to return bool.

[alexfh]

In D18821#399064, @Prazek wrote:

In D18821#398843, @alexfh wrote:

BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.

I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.

There were many places.

Would be nice, if you could tell the number and provide a list of locations. Have any of these been fixed since then?

[Prazek]

In D18821#399079, @alexfh wrote:

In D18821#399064, @Prazek wrote:

In D18821#398843, @alexfh wrote:

BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.

I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.

There were many places.

Would be nice, if you could tell the number and provide a list of locations. Have any of these been fixed since then?

No, I didn't know that I can do that - I always heard that I can't format code that I didn't change, so I though the same thing is here. I will try do post review of changes in clang/llvm soon.

[Prazek]

http://reviews.llvm.org/D19105
Here is a diff containing fixes for clang. What I see is that it would be nice to detect bitfields of 1 bit and treet it as bool, so it won't warn it such cases.

[Prazek]

I will think name for new module that would have all the checks like this.
I added ingnoring of bitfields of size 1

[Prazek]

In D18821#398843, @alexfh wrote:

BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.

I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.

Do you have any thought about the name for such a module? I belive that misc is overloaded.

So for this we are looking for something that is probably not a bug, but it makes code a little bit inaccurate
Maybe something like:

• accuracy,
• correctness,
• certainity,
• safety,
• maybebugmaybenothardtosay

[• Quuxplusone]

I would like to see a new version of http://reviews.llvm.org/D19105 with all the "1-bit-bitfield" diffs removed.
Right now, it's hard to see that there's *anything* in D19105 that's not a miscorrection of a 1-bit bitfield.

Do you have an example of a large codebase where this check runs with few false positives and a non-zero number of true positives?

[Prazek]

In D18821#403103, @Quuxplusone wrote:

I would like to see a new version of http://reviews.llvm.org/D19105 with all the "1-bit-bitfield" diffs removed.
Right now, it's hard to see that there's *anything* in D19105 that's not a miscorrection of a 1-bit bitfield.

Do you have an example of a large codebase where this check runs with few false positives and a non-zero number of true positives?

I will post fixex tomorrow. I don't think there will be any false or true positives in warnings, but the main problems with fixes are that many times developer wants to use bools, but it decalres field/return type as int.

[Prazek]

In D18821#402686, @Prazek wrote:

In D18821#398843, @alexfh wrote:

BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.

I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.

Do you have any thought about the name for such a module? I belive that misc is overloaded.

So for this we are looking for something that is probably not a bug, but it makes code a little bit inaccurate
Maybe something like:

• accuracy,
• correctness,
• certainity,
• safety,
• maybebugmaybenothardtosay

after a long though I think that "accuracy" is the best name here - we want to look for a code that is valid, but not accurate

[alexfh]

In D18821#403117, @Prazek wrote:

In D18821#402686, @Prazek wrote:

In D18821#398843, @alexfh wrote:

BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.

I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.

Do you have any thought about the name for such a module? I belive that misc is overloaded.

So for this we are looking for something that is probably not a bug, but it makes code a little bit inaccurate
Maybe something like:

• accuracy,
• correctness,
• certainity,
• safety,
• maybebugmaybenothardtosay

after a long though I think that "accuracy" is the best name here - we want to look for a code that is valid, but not accurate

There are many possible reasons this pattern can appear in the code. Sometimes it's a bug, sometimes, it's an attempt to make the code look better than it is ;) It seems to me though, that having a type mismatch of this kind is a bug-prone pattern, so I would start a more generic "bugprone" category of checks (and move some misc- checks there later on).

Also, please re-upload D19105 after disabling matches on 1-bit bitfields in the check.

[Prazek]

It seems that it works right now.
The other funny thing that the check found is cases like

bool b;
if (b == true)

I will update the llvm/clang changes today.
Do you want to see only the changes that clang-tidy made, or do you want to see it after some changing that I will do?

[Prazek]

Updated the diff with changes
http://reviews.llvm.org/D19105

[alexfh]

docs/clang-tidy/checks/bugprone-bool-to-integer-conversion.rst

43

This is a false positive and should be fixed regardless of whether we disable fixits or not. Just documenting it doesn't help much.

[Prazek]

+Fixed bug with operators
+ added fixup for function return type

I will post changes on clang tomorrow

[Prazek]

Some small bugfixes afeter running it on llvm

[Prazek]

aborting with virtual functions

[Prazek]

ping

[alexfh]

docs/clang-tidy/checks/bugprone-bool-to-integer-conversion.rst

38

It may well not be a bug. It's definitely not a bug for extern "C" functions and functions in C code. We definitely don't need to change the function return type, since it's a rather involved change (and clang-tidy checks currently are simply not able to make such change correctly in case of a function with external linkage). So please remove this automated fix.

42

Please check that your documentation compiles.

test/clang-tidy/bugprone-bool-to-integer-conversion.cpp

192

That's a dangerous fix. It should either be removed or guarded by an option.

[Prazek]

docs/clang-tidy/checks/bugprone-bool-to-integer-conversion.rst

38

This check runs only on C++ functions. Maybe checking that the function isExternC() would be enough?

test/clang-tidy/bugprone-bool-to-integer-conversion.cpp

193

Why it is dangerous? What I see after runnign on llvm code base, that it is one of the most frequent case.
The only bug is the extern "C" thing.

[alexfh]

Sorry for the delay. Your patch was lost in my inbox. Feel free to ping me earlier.

docs/clang-tidy/checks/bugprone-bool-to-integer-conversion.rst

38

As I've said, extern "C" is not the only way to make a function a part of an API exposed to external users.

test/clang-tidy/bugprone-bool-to-integer-conversion.cpp

193

Well, extern "C" is not the only way to expose functions to some external code. This fix potentially changes ABI, which is generally not a safe thing to do. I think, we should make the fix optional.

clang-tidy/CMakeLists.txt

add_clang_library(clangTidy
   clangStaticAnalyzerCore
   clangStaticAnalyzerFrontend
   clangTooling
   clangToolingCore
   )
 
 add_subdirectory(tool)
 add_subdirectory(plugin)
+add_subdirectory(bugprone)
 add_subdirectory(boost)
 add_subdirectory(cert)
 add_subdirectory(llvm)
 add_subdirectory(cppcoreguidelines)
 add_subdirectory(google)
 add_subdirectory(misc)
 add_subdirectory(modernize)
 add_subdirectory(performance)
 add_subdirectory(readability)
 add_subdirectory(utils)

clang-tidy/bugprone/BoolToIntegerConversionCheck.h

+//===--- BoolToIntegerConversionCheck.h - clang-tidy-------------*- C++ -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MODERNIZE_BOOL_TO_INTEGER_CONVERSION_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MODERNIZE_BOOL_TO_INTEGER_CONVERSION_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+/// Finds implicit casts of bool literal to integer types like int a = true,
+/// and replaces it with integer literals like int a = 1
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/modernize-bool-to-integer-conversion.html
+class BoolToIntegerConversionCheck : public ClangTidyCheck {
+public:
+  BoolToIntegerConversionCheck(StringRef Name, ClangTidyContext *Context)
+      : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+};
+
+} // namespace bugprone
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MODERNIZE_BOOL_TO_INTEGER_CONVERSION_H

clang-tidy/bugprone/BoolToIntegerConversionCheck.cpp

+//===--- BoolToIntegerConversionCheck.cpp - clang-tidy---------------------===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+#include "BoolToIntegerConversionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+AST_MATCHER(FieldDecl, isOneBitBitField) {
+  return Node.isBitField() &&
+         Node.getBitWidthValue(Finder->getASTContext()) == 1;
+}
+
+void BoolToIntegerConversionCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+    return;
+
+  auto convertingToOneBitBitfieldInInitializer = hasAncestor(
+      cxxConstructorDecl(hasAnyConstructorInitializer(cxxCtorInitializer(
+          forField(isOneBitBitField()),
+          withInitializer(implicitCastExpr(equalsBoundNode("cast")))))));
+
+  auto convertingToOneBitBitfieldByOperator =
+      hasParent(binaryOperator(hasLHS(memberExpr(
+          hasDeclaration(fieldDecl(isOneBitBitField()).bind("bitfield"))))));
+
+  Finder->addMatcher(
+      stmt(allOf(implicitCastExpr(has(cxxBoolLiteral().bind("bool_literal")))
+                     .bind("cast"),
+                 unless(anyOf(convertingToOneBitBitfieldByOperator,
+                              convertingToOneBitBitfieldInInitializer)))),
+      this);
+}
+
+void BoolToIntegerConversionCheck::check(
+    const MatchFinder::MatchResult &Result) {
+
+  const auto *BoolLiteral =
+      Result.Nodes.getNodeAs<CXXBoolLiteralExpr>("bool_literal");
+  const auto *Cast = Result.Nodes.getNodeAs<ImplicitCastExpr>("cast");
+  const auto Type = Cast->getType().getLocalUnqualifiedType();
+  auto Location = BoolLiteral->getLocation();
+
+  auto Diag = diag(Location,
+                   "implicitly converting bool literal to %0%select{| inside a "
+                   "macro}1; use integer literal instead")
+              << Type;
+
+  if (Location.isMacroID())
+    Diag << 1;
+  else
+    Diag << 0
+         << FixItHint::CreateReplacement(BoolLiteral->getSourceRange(),
+                                         BoolLiteral->getValue() ? "1" : "0");
+}
+
+} // namespace bugprone
+} // namespace tidy
+} // namespace clang

clang-tidy/bugprone/BugProneModule.cpp

+//===------- BugProneTidyModule.cpp - clang-tidy --------------------------===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+#include "../ClangTidy.h"
+#include "../ClangTidyModule.h"
+#include "../ClangTidyModuleRegistry.h"
+#include "BoolToIntegerConversionCheck.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+class BugProneModule : public ClangTidyModule {
+public:
+  void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
+    CheckFactories.registerCheck<BoolToIntegerConversionCheck>(
+      "bugprone-bool-to-integer-conversion");
+  }
+};
+
+// Register the BoostModule using this statically initialized variable.
+static ClangTidyModuleRegistry::Add<BugProneModule> X("bugprone-module",
+                                                   "Add bugprone checks.");
+
+} // namespace bugprone
+
+// This anchor is used to force the linker to link in the generated object file
+// and thus register the BoostModule.
+volatile int BugProneModuleAnchorSource = 0;
+
+} // namespace tidy
+} // namespace clang

clang-tidy/bugprone/CMakeLists.txt

+set(LLVM_LINK_COMPONENTS support)
+
+add_clang_library(clangTidyBugProneModule
+  BugProneModule.cpp
+  BoolToIntegerConversionCheck.cpp
+
+  LINK_LIBS
+  clangAST
+  clangASTMatchers
+  clangBasic
+  clangLex
+  clangTidy
+  clangTidyUtils
+  )

clang-tidy/plugin/CMakeLists.txt

 add_clang_library(clangTidyPlugin
   ClangTidyPlugin.cpp
 
   LINK_LIBS
   clangAST
   clangASTMatchers
   clangBasic
   clangFrontend
   clangSema
   clangTidy
+  clangTidyBugProneModule
   clangTidyBoostModule
   clangTidyCERTModule
   clangTidyCppCoreGuidelinesModule
   clangTidyGoogleModule
   clangTidyLLVMModule
   clangTidyMiscModule
   clangTidyModernizeModule
   clangTidyPerformanceModule
   clangTidyReadabilityModule
   clangTooling
   )

clang-tidy/tool/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS
   support
   )
 
 add_clang_executable(clang-tidy
   ClangTidyMain.cpp
   )
 target_link_libraries(clang-tidy
   clangAST
   clangASTMatchers
   clangBasic
   clangTidy
+  clangTidyBugProneModule
   clangTidyBoostModule
   clangTidyCERTModule
   clangTidyCppCoreGuidelinesModule
   clangTidyGoogleModule
   clangTidyLLVMModule
   clangTidyMiscModule
   clangTidyModernizeModule
   clangTidyPerformanceModule

clang-tidy/tool/ClangTidyMain.cpp

if (WErrorCount) {
     llvm::errs() << WErrorCount << " warning" << Plural << " treated as error"
                  << Plural << "\n";
     return WErrorCount;
   }
 
   return 0;
 }
 
+// This anchor is used to force the linker to link the BugProneModule.
+extern volatile int BugProneModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED BugProneModuleAnchorDestination =
+    BugProneModuleAnchorSource;
+
 // This anchor is used to force the linker to link the CERTModule.
 extern volatile int CERTModuleAnchorSource;
 static int LLVM_ATTRIBUTE_UNUSED CERTModuleAnchorDestination =
     CERTModuleAnchorSource;
 
 // This anchor is used to force the linker to link the BoostModule.
 extern volatile int BoostModuleAnchorSource;
 static int LLVM_ATTRIBUTE_UNUSED BoostModuleAnchorDestination =

docs/ReleaseNotes.rst

 
 Improvements to clang-tidy
 --------------------------
 
 :program:`clang-tidy`'s checks are constantly being improved to catch more issues,
 explain them more clearly, and provide more accurate fix-its for the issues
 identified.  The improvements since the 3.8 release include:
 
+- New bugprone module containing checks looking for bugprone code.
+
+- New `bugprone-bool-to-integer-conversion
+  <http://clang.llvm.org/extra/clang-tidy/checks/bugprone-bool-to-integer-conversion.html>`_ check
+
+  Replaces bool literals which are being implicitly cast to integers with integer literals.
+
 - New Boost module containing checks for issues with Boost library.
 
 - New `boost-use-to-string 
   <http://clang.llvm.org/extra/clang-tidy/checks/boost-use-to-string.html>`_ check
 
   Finds usages of ``boost::lexical_cast<std::string>`` and changes it to
   ``std::to_string``.
 

 - New `modernize-deprecated-headers
   <http://clang.llvm.org/extra/clang-tidy/checks/modernize-deprecated-headers.html>`_ check
 
   Replaces C standard library headers with their C++ alternatives.
 
 - New `modernize-make-shared
   <http://clang.llvm.org/extra/clang-tidy/checks/modernize-make-shared.html>`_ check
 
   Replaces creation of ``std::shared_ptr`` from new expression with call to ``std::make_shared``.
 
 - New `modernize-raw-string-literal
   <http://clang.llvm.org/extra/clang-tidy/checks/modernize-raw-string-literal.html>`_ check
 
   Selectively replaces string literals containing escaped characters with raw
   string literals.
 
 - New `performance-faster-string-find

docs/clang-tidy/checks/bugprone-bool-to-integer-conversion.rst

+.. title:: clang-tidy - bugprone-bool-to-integer-conversion
+
+bugprone-bool-to-integer-conversion
+====================================
+
+This check looks for implicit conversion from bool literals to integer types
+
+.. code-block:: C++
+
+  int a = false;
+  vector<bool> v(true); // Makes vector of one element
+
+  // Changes it to
+  int a = 0;
+  vector<bool> v(1); // Makes vector of one element
+
+Because bitfields packing are compiler dependent, check treats single-bit
+bitfields as bools
+
+.. code-block:: C++
+
+  struct BitFields {
+    BitFields() : notAFlag(true), b(false) {}
+    unsigned notAFlag : 3;
+    unsigned flag : 1;
+  };
+
+  // Changes to
+  struct BitFields {
+    BitFields() : notAFlag(1), b(false) {}
+    unsigned notAFlag : 3;
+    unsigned flag : 1;
+  };
+
+Note: be aware that check will fire for code:
+
+.. code-block:: C++
+
+    bool p;
+    auto z = p == true;
+    //            ^
+
+This is because z and ``true`` will be implicitly converted to int by promotion.
+To get rid of this case use
+`readability-simplify-boolean-expr
+<http://clang.llvm.org/extra/clang-tidy/checks/readability-simplify-boolean-expr.html>`_.
+

docs/clang-tidy/checks/list.rst

.. toctree::
    misc-throw-by-value-catch-by-reference
    misc-undelegated-constructor
    misc-uniqueptr-reset-release
    misc-unused-alias-decls
    misc-unused-parameters
    misc-unused-raii
    misc-unused-using-decls
    misc-virtual-near-miss
+   modernize-bool-to-integer-conversion
    modernize-deprecated-headers
    modernize-loop-convert
    modernize-make-shared
    modernize-make-unique
    modernize-pass-by-value
    modernize-raw-string-literal
    modernize-redundant-void-arg
    modernize-replace-auto-ptr

docs/clang-tidy/index.rst

 * The ``readability-`` checks target readability-related issues that don't
   relate to any particular coding style.
 
 * Checks with names starting with ``misc-`` the checks that we didn't have a
   better category for.
 
 * Clang static analyzer checks are named starting with ``clang-analyzer-``.
 
-* Checks related to Boost library starts with ``boost-``. 
-  
+* Checks related to Boost library starts with ``boost-``.
+* The ``bugprone-*`` checks target code that have some potential bugs.
+  
 Clang diagnostics are treated in a similar way as check diagnostics. Clang
 diagnostics are displayed by clang-tidy and can be filtered out using
 ``-checks=`` option. However, the ``-checks=`` option does not affect
 compilation arguments, so it can not turn on Clang warnings which are not
 already turned on in build configuration. The ``-warnings-as-errors=`` option
 upgrades any warnings emitted under the ``-checks=`` flag to errors (but it
 does not enable any checks itself).
 

 
 Next, you need to decide which module the check belongs to. If the check
 verifies conformance of the code to a certain coding style, it probably deserves
 a separate module and a directory in ``clang-tidy/``. There are already modules
 implementing checks related to:
 
 * `C++ Core Guidelines
   <http://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/>`_
+* potential `bugprone code
+  <http://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/bugprone/>`_
 * `CERT Secure Coding Standards
   <http://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/cert/>`_
 * `Google Style Guide
   <http://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/google/>`_
 * `LLVM Style
   <http://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/llvm/>`_
 * `modernizing C/C++ code
   <http://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/modernize/>`_

test/clang-tidy/bugprone-bool-to-integer-conversion.cpp

+// RUN: %check_clang_tidy %s bugprone-bool-to-integer-conversion %t
+
+const int is42Answer = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: implicitly converting bool literal to 'int'; use integer literal instead [bugprone-bool-to-integer-conversion]
+// CHECK-FIXES: const int is42Answer = 1;{{$}}
+
+volatile int noItsNot = false;
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: implicitly converting bool literal to 'int'; {{..}}
+// CHECK-FIXES: volatile int noItsNot = 0;{{$}}
+int a = 42;
+int az = a;
+
+long long ll = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: implicitly converting bool literal to 'long long';{{..}}
+// CHECK-FIXES: long long ll = 1;{{$}}
+
+void fun(int) {}
+#define ONE true
+
+// No fixup for macros.
+int one = ONE;
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: implicitly converting bool literal to 'int' inside a macro; use integer literal instead [bugprone-bool-to-integer-conversion]
+
+void test() {
+  fun(ONE);
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: implicitly converting bool{{..}}
+
+  fun(42);
+  fun(true);
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: implicitly {{..}}
+// CHECK-FIXES: fun(1);{{$}}
+}
+
+char c = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: implicitly {{..}}
+// CHECK-FIXES: char c = 1;
+
+float f = false;
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: implicitly converting bool literal to 'float';{{..}}
+// CHECK-FIXES: float f = 0;
+
+struct Blah {
+  Blah(int blah) { }
+};
+
+const int &ref = false;
+// CHECK-MESSAGES: :[[@LINE-1]]:18: warning: implicitly converting bool literal to 'int'{{..}}
+// CHECK-FIXES: const int &ref = 0;
+
+Blah bla = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: implicitly converting bool literal to 'int'{{..}}
+// CHECK-FIXES: Blah bla = 1;
+
+Blah bla2 = 1;
+
+char c2 = 1;
+char c3 = '0';
+bool b = true;
+
+// Don't warn of bitfields of size 1. Unfortunately we can't just
+// change type of flag to bool, because some compilers like MSVC doesn't
+// pack bitfields of different types.
+struct BitFields {
+  BitFields() : a(true), flag(false) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:19: warning: implicitly converting
+// CHECK-FIXES: BitFields() : a(1), flag(false) {}
+
+  unsigned a : 3;
+  unsigned flag : 1;
+};
+
+void testBitFields() {
+  BitFields b;
+  b.flag = true;
+  b.a = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: implicitly converting
+// CHECK-FIXES: b.a = 1;
+}
+