[clang-tidy] Infinite loop checker

[szepet]

Summary

The check aims to find loops where none of the condition variables are updated in the body.
In this version it only works on integer types but the final aim is to make it work for objects as well. (via checking non-const method calls, etc)

Note: this kind of check is supported by clang warning as well (-Wfor-loop-analysis), however, it only works on for-loops and not investigate escape statements (modification via alias generates false positives e.g. escape_before1() test case).

Any suggestions on the check are welcome!

[Eugene.Zelenko]

Does it really belong to Clang-tidy or Clang Analyzer is better place because of path-ensitivity?

Please rebase from trunk.

General note: CLang-tidy use check in terminology, not checker.

docs/ReleaseNotes.rst

63

Just Finds instead of The checker aims to find. Please also align on 80 symbols per line. Same in documentation.

[szepet]

Updated the wording in the docs.

[szepet]

Hi Eugen!
Good question, probably should have detailed it in the description.
This matcher based solution would not gain much benefit from the symbolic execution provided information. (I mean, it would mean a much different type of check on the states.)
The main problems that the analyzer does not completely unroll the loops only the first steps and we always have information about the simulated path. However, detecting that some variables will surely not be modified requires a top level overview on the loop and the AST provides these informations. The one thing (that I can say right now) that can come handy is that we would able to detect more precisely the happened-before relation on the escape and the loop statements. Since the CFG can provide us fair enough information on this one, I do not think that this is enough reason to put this checker to the analyzer.

Other note: If somebody would came up with an approach which can benefit from the symbolic execution, these solutions could still live happily in the different tools eg. UseAfterMove (tidy) and MisusedMovedObjectChecker (analyzer).

[Eugene.Zelenko]

In D40937#947658, @szepet wrote:

Other note: If somebody would came up with an approach which can benefit from the symbolic execution, these solutions could still live happily in the different tools eg. UseAfterMove (tidy) and MisusedMovedObjectChecker (analyzer).

I'm more concerned with path sensitivity and reporting. From my point of view UseAfterMove also belongs to Analyzer realm.

Actually bugprone module may be better choice then misc.

docs/ReleaseNotes.rst

63

Please remove The check. See other checks release notes and documentation as style examples.

Please rebase from trunk, since I sorted Clang-tidy notes recently, so just prefer to avoid this task in future :-)

[Eugene.Zelenko]

clang-tidy/misc/InfiniteLoopCheck.cpp

94 ↗

(On Diff #125870)

Missing static?

102 ↗

(On Diff #125870)

May be return {}?

125 ↗

(On Diff #125870)

const auto?

130 ↗

(On Diff #125870)

const auto?

142 ↗

(On Diff #125870)

const auto?

168 ↗

(On Diff #125870)

const auto?

176 ↗

(On Diff #125870)

const auto?

[JVApen]

How does this check deal with atomic members?

struct A {
std:: atomic<bool> a;

void f() const { while (a); }
};

[martong]

clang-tidy/misc/InfiniteLoopCheck.cpp

105 ↗

(On Diff #125870)

make_unique is a forwarding function, therefore there is no need to create an object and then move it. Instead you can simply forward the arguments to the constructor:
return llvm::make_unique<ExprSequence>(TheCFG.get(), &ASTCtx)

[szepet]

Updates based on comments.

[Eugene.Zelenko]

docs/clang-tidy/checks/misc-infinite-loop.rst

6 ↗

(On Diff #125965)

Please synchronize with release notes.

[szepet]

In D40937#947760, @JVApen wrote:

How does this check deal with atomic members?
...

This patch only works on integer types. So, since the atomic is a non-supported type the check will skip that while loop.

[xazax.hun]

This does not support memberExprs as condition variables right now.

What happens if you have something like this:

struct X {
void f(int a) {
  while(a < i) {
    --i;
  } 
}
int i;
};

I think you could extend the test cases with some classes.

clang-tidy/misc/InfiniteLoopCheck.cpp

28 ↗

(On Diff #125870)

Do you need this to be a lambda? Can't you just use a local variable?

31 ↗

(On Diff #125870)

Maybe this is not too important, but you might also want to check for blocks here.

48 ↗

(On Diff #125870)

This can be greatly simplified once https://reviews.llvm.org/D38921 is accepted. Maybe you could use that as a dependent revision? It should be close to be accepted.

[xazax.hun]

clang-tidy/misc/InfiniteLoopCheck.cpp

121 ↗

(On Diff #125965)

This could be pointer to const, right?

[aaron.ballman]

I share the concerns that @Eugene.Zelenko brought up regarding this not being in the analyzer. This is a path sensitive problem that I'm not certain clang-tidy is the best home for. You cover many of the simple cases, but fail to cover cases like nested loops, unsigned integer wrapping, non-integral types, function calls, globals, etc. I'm not certain this check will generalize over time as part of clang-tidy in the way it would in the analyzer. I'd be curious to hear what @alexfh and @dcoughlin think, though.

[xazax.hun]

I think, while the analyzer is more suitable for certain kinds of checks that require deep analysis, it is still useful to have quicker syntactic checks that can easily identify problems that are the results of typos or incorrectly modified copy and pasted code. I think this check is in that category. Also, the original warning Peter mentioned does something similar but has some shortcomings.

The current implementation is not path sensitive. It uses flow sensitivity to check for escaping values.
If we would try to port this check to the static analyzer, the questions we would ask from the analyzer are universally quantified (e.g. for all path this variable does not escape and does not change). Unfortunately, it is not that easy with the current analyzer to answer such questions. The static analyzer is better with existential questions (e.g. there is a path such that the condition variables are not escaped and are unchanged in the loop). Using the latter formulation we might have a larger number of false positives because the analyzer sometimes hit infeasible paths. In the first approach, the infeasible paths are less of a problem (they might cause false negatives but not false positives), but we need to be careful with all the peculiarities of the analyzer because it does not guarantee to discover all possible paths.

Hopefully, Devin will correct me if I'm wrong :)

[alexfh]

Please move this check to "bugprone-", since it seems to be an appropriate category for this check.

[szepet]

Moved to bugprone category,
skipping memberExpr cases for now in order to avoid false positives,
other small changes based on review comments.

clang-tidy/misc/InfiniteLoopCheck.cpp

121 ↗

(On Diff #125965)

Since the createSequence uses it as a parameter for buildCFG which expects a Stmt*, I believe this is fine. (Or I could const cast is away on the call)

[alexfh]

clang-tidy/bugprone/InfiniteLoopCheck.cpp

23–25

This doesn't have to be a function. It can be a local variable or can be inlined into the callsite.

32

http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly

Variable names should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. Leader or Boats).

105

Why not just llvm::make_unique<ExprSequence>(TheCFG.get(), &ASTCtx)?

It also may be that you somehow lost a bunch of fixes, since this comment has already been addressed at some point: https://reviews.llvm.org/D40937?id=125870#inline-357357

186

Clang diagnostics (and clang-tidy warnings) are not complete sentences and shouldn't start with a capital letter.

[szepet]

Addressed comments and readded the lost fixes.

[alexfh]

clang-tidy/bugprone/InfiniteLoopCheck.cpp

95–100

A little suggestion:

if (std::unique_ptr<CFG> TheCFG = ...)
  return llvm::make_unique<ExprSequence>(TheCFG.get(), &ASTCtx);
return {};

129

The main concern I have now is that the check may end up creating the CFG multiple times for the same function, which may be rather expensive in certain cases (consider a large function consisting of loops that trigger the matcher). It's hard to predict how common is this situation in real code. Do you see how this could be restructured to avoid unnecessary work?

180

I suggest a more straightforward version:

​ std::string CondVarNames;

for (const auto &CVM : CondVarMatches) {
  if (!CondVarNames.empty())
    CondVarNames.append(", ");
  CondVarNames.append(CVM.getNodeAs<VarDecl>("condvar")->getNameAsString());

​ }

[szepet]

Changes made based on comments.
The CFG recreating problem is handled the following (only for this check):
Always store the last visited function and its CFG* (in form of the Sequence*) and check if we are visiting it again. If so, then the check reuses the previous one, if not, then replaces them. As far as I know the AST traverse done by the tidy fits this model (at least for this check, since it not uses narrowing matchers to other functions).
Sure, it would be better to find a general solution to this problem, and make the CFG reusable by every check which needs it, but I would left it for a follow-up (and a change like this probably would worth an own patch/review anyway).

[alexfh]

clang-tidy/bugprone/InfiniteLoopCheck.h

38

Why bool? The return value is not used anywhere.

docs/ReleaseNotes.rst

68

There should be a trailing period in each of these New ... check items. I've updated the script in r331460 and the existing release notes in r331461. Please rebase.

[szepet]

Changes based on comments.

[alexfh]

Could you run the check on llvm sources and post a summary of results here?

A few more inline comments.

clang-tidy/bugprone/InfiniteLoopCheck.cpp

103

What does nullptr mean here? Please add an argument comment (/*ArgumentName=*/nullptr, ...).

110–113

nit: Let's put these variable definitions into the corresponding if conditions to limit their scope. I'd also move the ifs to the start of the function.

123–124

Instead I'd check that FunctionBody is not nullptr.

149

nit: const auto *

151

Any reason to store the result of the matching instead of returning early? Same below. Please also move the definition of the Match variable to where it's actually needed first time.

176

Please use the specific type instead of auto.

clang-tidy/bugprone/InfiniteLoopCheck.h

38

You seem to have forgotten to update the header.

clang-tidy/bugprone/BugproneTidyModule.cpp

 #include "BoolPointerImplicitConversionCheck.h"
 #include "CopyConstructorInitCheck.h"
 #include "DanglingHandleCheck.h"
 #include "FoldInitTypeCheck.h"
 #include "ForwardDeclarationNamespaceCheck.h"
 #include "ForwardingReferenceOverloadCheck.h"
 #include "InaccurateEraseCheck.h"
 #include "IncorrectRoundingsCheck.h"
+#include "InfiniteLoopCheck.h"
 #include "IntegerDivisionCheck.h"
 #include "LambdaFunctionNameCheck.h"
 #include "MacroParenthesesCheck.h"
 #include "MacroRepeatedSideEffectsCheck.h"
 #include "MisplacedOperatorInStrlenInAllocCheck.h"
 #include "MisplacedWideningCastCheck.h"
 #include "MoveForwardingReferenceCheck.h"
 #include "MultipleStatementMacroCheck.h"
void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
     CheckFactories.registerCheck<ForwardDeclarationNamespaceCheck>(
         "bugprone-forward-declaration-namespace");
     CheckFactories.registerCheck<ForwardingReferenceOverloadCheck>(
         "bugprone-forwarding-reference-overload");
     CheckFactories.registerCheck<InaccurateEraseCheck>(
         "bugprone-inaccurate-erase");
     CheckFactories.registerCheck<IncorrectRoundingsCheck>(
         "bugprone-incorrect-roundings");
+    CheckFactories.registerCheck<InfiniteLoopCheck>(
+        "bugprone-infinite-loop");
     CheckFactories.registerCheck<IntegerDivisionCheck>(
         "bugprone-integer-division");
     CheckFactories.registerCheck<LambdaFunctionNameCheck>(
         "bugprone-lambda-function-name");
     CheckFactories.registerCheck<MacroParenthesesCheck>(
         "bugprone-macro-parentheses");
     CheckFactories.registerCheck<MacroRepeatedSideEffectsCheck>(
         "bugprone-macro-repeated-side-effects");

clang-tidy/bugprone/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangTidyBugproneModule
   ArgumentCommentCheck.cpp
   AssertSideEffectCheck.cpp
   BoolPointerImplicitConversionCheck.cpp
   BugproneTidyModule.cpp
   CopyConstructorInitCheck.cpp
   DanglingHandleCheck.cpp
   FoldInitTypeCheck.cpp
   ForwardDeclarationNamespaceCheck.cpp
   ForwardingReferenceOverloadCheck.cpp
   InaccurateEraseCheck.cpp
   IncorrectRoundingsCheck.cpp
+  InfiniteLoopCheck.cpp
   IntegerDivisionCheck.cpp
   LambdaFunctionNameCheck.cpp
   MacroParenthesesCheck.cpp
   MacroRepeatedSideEffectsCheck.cpp
   MisplacedOperatorInStrlenInAllocCheck.cpp
   MisplacedWideningCastCheck.cpp
   MoveForwardingReferenceCheck.cpp
   MultipleStatementMacroCheck.cpp

clang-tidy/bugprone/InfiniteLoopCheck.h

+//===--- InfiniteLoopCheck.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_BUGPRONE_INFINITELOOPCHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_BUGPRONE_INFINITELOOPCHECK_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+/// The check aims to find loops where none of the condition variables are
+/// updated in the body. This performs a very conservative check in order to
+/// avoid false positives and work only on integer types at the moment.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/bugprone-infinite-loop.html
+class InfiniteLoopCheck : public ClangTidyCheck {
+public:
+  InfiniteLoopCheck(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_BUGPRONE_INFINITELOOPCHECK_H

clang-tidy/bugprone/InfiniteLoopCheck.cpp

+//===--- InfiniteLoopCheck.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 "InfiniteLoopCheck.h"
+#include "../utils/ExprSequence.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/CFG.h"
+
+using namespace clang::ast_matchers;
+using namespace clang::tidy::utils;
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+static internal::Matcher<Stmt> loopEndingStmt() {
+  return stmt(anyOf(breakStmt(), returnStmt(), gotoStmt(), cxxThrowExpr()));
+}
+
+static internal::Matcher<Expr> exprAccessToVar(const VarDecl *VD) {
+  return ignoringParenImpCasts(declRefExpr(hasDeclaration(equalsNode(VD))));
+}
+
+void InfiniteLoopCheck::registerMatchers(MatchFinder *Finder) {
+  const auto loopCondition = allOf(hasCondition(expr().bind("condition")),
+              anyOf(hasAncestor(lambdaExpr().bind("containing-lambda")),
+                    hasAncestor(functionDecl().bind("containing-func"))),
+              unless(hasBody(hasDescendant(loopEndingStmt()))));
+
+  Finder->addMatcher(
+      stmt(anyOf(whileStmt(loopCondition), doStmt(loopCondition),
+                 forStmt(loopCondition)))
+          .bind("loop-stmt"),
+      this);
+}
+
+static internal::Matcher<Stmt>
+changeByOperator(internal::Matcher<Expr> ExprNodeMatcher) {
+  return anyOf(
+      unaryOperator(anyOf(hasOperatorName("--"), hasOperatorName("++")),
+                    hasUnaryOperand(ignoringParenImpCasts(
+                        ExprNodeMatcher))),
+                    binaryOperator(isAssignmentOperator(),
+                     hasLHS(ExprNodeMatcher)));
+}
+
+static internal::Matcher<Stmt>
+callByRef(internal::Matcher<Expr> ExprNodeMatcher) {
+  return callExpr(forEachArgumentWithParam(
+      ExprNodeMatcher,
+      parmVarDecl(hasType(references(qualType(unless(isConstQualified())))))));
+}
+
+static internal::Matcher<Stmt>
+assignedToRef(internal::Matcher<Expr> ExprNodeMatcher) {
+  return declStmt(hasDescendant(varDecl(
+      allOf(hasType(referenceType()),
+            hasInitializer(anyOf(
+                initListExpr(has(ExprNodeMatcher)),
+                ExprNodeMatcher))))));
+}
+
+static internal::Matcher<Stmt>
+getAddrTo(internal::Matcher<Expr> ExprNodeMatcher) {
+  return unaryOperator(
+      hasOperatorName("&"),
+      hasUnaryOperand(ExprNodeMatcher));
+}
+
+static internal::Matcher<Stmt> escapeStmt(const VarDecl *VD) {
+  // Escaping is covered as address-of operators, pass-by-ref function calls and
+  // reference initialization on the variable body.
+  return stmt(anyOf(callByRef(exprAccessToVar(VD)), getAddrTo(exprAccessToVar(VD)),
+                    assignedToRef(exprAccessToVar(VD))));
+}
+
+static internal::Matcher<Stmt> hasDescendantOrIsItselfStmt(internal::Matcher<Stmt> VarNodeMatcher) {
+  return anyOf(VarNodeMatcher, hasDescendant(VarNodeMatcher));
+}
+
+static internal::Matcher<Stmt> potentiallyModifyVarStmt(const VarDecl *VD) {
+  return hasDescendantOrIsItselfStmt(anyOf(changeByOperator(exprAccessToVar(VD)),
+                                           escapeStmt(VD)));
+}
+
+
+std::unique_ptr<ExprSequence> createSequence(Stmt *FunctionBody,
+                                             ASTContext &ASTCtx) {
+  CFG::BuildOptions Options;
+  Options.AddImplicitDtors = true;
+  Options.AddTemporaryDtors = true;
+  std::unique_ptr<CFG> TheCFG =
+      CFG::buildCFG(nullptr, FunctionBody, &ASTCtx, Options);
+  if (!TheCFG)
+    return std::unique_ptr<ExprSequence>();
+
+  return llvm::make_unique<ExprSequence>(
+      *(new ExprSequence(TheCFG.get(), &ASTCtx)));
+}
+
+void InfiniteLoopCheck::check(const MatchFinder::MatchResult &Result) {
+  const auto *ContainingLambda =
+      Result.Nodes.getNodeAs<LambdaExpr>("containing-lambda");
+  const auto *ContainingFunc =
+      Result.Nodes.getNodeAs<FunctionDecl>("containing-func");
+  const auto *Cond = Result.Nodes.getNodeAs<Expr>("condition");
+  const auto *LoopStmt = Result.Nodes.getNodeAs<Stmt>("loop-stmt");
+  auto &ASTCtx = *Result.Context;
+
+  Stmt *FunctionBody = nullptr;
+  if (ContainingLambda)
+    FunctionBody = ContainingLambda->getBody();
+  else if (ContainingFunc)
+    FunctionBody = ContainingFunc->getBody();
+  else
+    return;
+
+  auto CondVarMatches =
+      match(findAll(declRefExpr(to(varDecl().bind("condvar")))), *Cond, ASTCtx);
+
+  // Since MemberExprs can be modified by outer functions this case is excluded right now.
+  auto MemberExprsInCond = match(hasDescendantOrIsItselfStmt(memberExpr()), *Cond, ASTCtx);
+  if (!MemberExprsInCond.empty())
+    return;
+  std::unique_ptr<ExprSequence> Sequence = createSequence(FunctionBody, ASTCtx);
+
+  for (auto &E : CondVarMatches) {
+    auto CondVar = E.getNodeAs<VarDecl>("condvar");
+    // TODO: handle cases with non-integer condition variables
+    if (!CondVar->getType().getTypePtr()->isIntegerType())
+      return;
+
+    // In case the loop potentially changes any of the condition variables we
+    // assume the loop is not infinite.
+    SmallVector<BoundNodes, 1> Match;
+    // In case of for loop we check the increment stmt and the body for changes
+    // (excluding the init stmt).
+    if (auto ForLoop = dyn_cast<ForStmt>(LoopStmt)) {
+      if (ForLoop->getInc())
+        Match = match(potentiallyModifyVarStmt(CondVar), *ForLoop->getInc(),
+                      ASTCtx);
+      if (Match.empty() && ForLoop->getBody())
+        Match = match(potentiallyModifyVarStmt(CondVar), *ForLoop->getBody(),
+                      ASTCtx);
+    } else {
+      // In cases of while and do-while we can match the whole loop.
+      Match = match(potentiallyModifyVarStmt(CondVar), *LoopStmt, ASTCtx);
+    }
+    if (!Match.empty())
+      return;
+
+    // Skip the cases where any of the condition variables come from outside
+    // of the function in order to avoid false positives.
+    Match = match(stmt(hasDescendant(varDecl(equalsNode(CondVar)))),
+                  *FunctionBody, ASTCtx);
+    if (Match.empty())
+      return;
+
+    // When a condition variable is escaped before the loop we skip since we
+    // have no precise pointer analysis and want to avoid false positives.
+    Match = match(
+        stmt(forEachDescendant(stmt(escapeStmt(CondVar)).bind("escStmt"))),
+        *FunctionBody, ASTCtx);
+
+    for (auto &ES : Match) {
+      if (Sequence->potentiallyAfter(LoopStmt, ES.getNodeAs<Stmt>("escStmt")))
+        return;
+    }
+  }
+
+  // Creating the string containing the name of condition variables.
+  std::string CondVarNames;
+  for (auto &CVM : CondVarMatches) {
+    CondVarNames += CVM.getNodeAs<VarDecl>("condvar")->getNameAsString() + ", ";
+  }
+  CondVarNames.resize(CondVarNames.size() - 2);
+
+  diag(LoopStmt->getLocStart(),
+       "%plural{1:The condition variable|:None of the condition variables}0 "
+       "(%1) %plural{1:is not|:are}0 updated in the loop body")
+      << (unsigned)CondVarMatches.size() << CondVarNames;
+}
+
+} // namespace bugprone
+} // namespace tidy
+} // namespace clang

docs/ReleaseNotes.rst

 The improvements are...
 
 Improvements to clang-tidy
 --------------------------
 
 - New module `abseil` for checks related to the `Abseil <https://abseil.io>`_
   library.
 
 - New module ``portability``.
 
 - New module ``zircon`` for checks related to Fuchsia's Zircon kernel.
 
+- New :doc:`bugprone-infinite-loop
+  <http://clang.llvm.org/extra/clang-tidy/checks/bugprone-infinite-loop.html>` check
+
+  Warns on loops where none of the condition variables are updated in the
+  body.
+
 - New :doc:`bugprone-throw-keyword-missing
   <clang-tidy/checks/bugprone-throw-keyword-missing>` check
 
   Diagnoses when a temporary object that appears to be an exception is
   constructed but not thrown.
 
 - New :doc:`bugprone-unused-return-value
   <clang-tidy/checks/bugprone-unused-return-value>` check

docs/clang-tidy/checks/bugprone-infinite-loop.rst

+.. title:: clang-tidy - bugprone-infinite-loop
+
+bugprone-infinite-loop
+======================
+
+Finds loops where none of the condition variables are updated in the body. This
+performs a very conservative check in order to avoid false positives and work
+only on integer types at the moment.
+
+Examples:
+
+.. code-block:: c++
+
+  void simple_infinite_loop() {
+    int i = 0;
+    int j = 0;
+    int Limit = 10;
+    while (i < Limit) { // Error, since none of the variables are updated.
+      j++;
+    }
+  }
+
+  void escape_before() {
+    int i = 0;
+    int Limit = 100;
+    int *p = &i;
+    while (i < Limit) { // Not an error, since p is alias of i.
+      *++p;
+    }
+  }

docs/clang-tidy/checks/list.rst

.. toctree::
    bugprone-bool-pointer-implicit-conversion
    bugprone-copy-constructor-init
    bugprone-dangling-handle
    bugprone-fold-init-type
    bugprone-forward-declaration-namespace
    bugprone-forwarding-reference-overload
    bugprone-inaccurate-erase
    bugprone-incorrect-roundings
+   bugprone-infinite-loop
    bugprone-integer-division
    bugprone-lambda-function-name
    bugprone-macro-parentheses
    bugprone-macro-repeated-side-effects
    bugprone-misplaced-operator-in-strlen-in-alloc
    bugprone-misplaced-widening-cast
    bugprone-move-forwarding-reference
    bugprone-multiple-statement-macro

test/clang-tidy/bugprone-infinite-loop.cpp

+// RUN: %check_clang_tidy %s bugprone-infinite-loop %t
+
+void simple_infinite_loop1() {
+  int i = 0;
+  int j = 0;
+  while (i < 10) {
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: The condition variable (i) is not updated in the loop body [bugprone-infinite-loop]
+    j++;
+  }
+
+  do {
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: The condition variable (i) is not updated in the loop body
+    j++;
+  } while (i < 10);
+
+  for (i = 0; i < 10; ++j) {
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: The condition variable (i) is not updated in the loop body
+  }
+}
+
+void simple_infinite_loop2() {
+  int i = 0;
+  int j = 0;
+  int Limit = 10;
+  while (i < Limit) {
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: None of the condition variables (i, Limit) are updated in the loop body [bugprone-infinite-loop]
+    j++;
+  }
+
+  do {
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: None of the condition variables (i, Limit) are updated in the loop body
+    j++;
+  } while (i < Limit);
+
+  for (i = 0; i < Limit; ++j) {
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: None of the condition variables (i, Limit) are updated in the loop body
+  }
+}
+
+void simple_not_infinite() {
+  int i = 0;
+  int Limit = 100;
+  while (i < Limit) { // Not an error since 'Limit' is updated
+    Limit--;
+  }
+  do {
+    Limit--;
+  } while (i < Limit);
+
+  for (i = 0; i < Limit; Limit--) {
+  }
+}
+
+void escape_before1() {
+  int i = 0;
+  int Limit = 100;
+  int *p = &i;
+  while (i < Limit) { // Not an error, since p is alias of i.
+    *++p;
+  }
+
+  do {
+    *++p;
+  } while (i < Limit);
+
+  for (i = 0; i < Limit; *++p) {
+    ;
+  }
+}
+
+void escape_before2() {
+  int i = 0;
+  int Limit = 100;
+  int *p = &i;
+  while (i < Limit) { // We do not warn since the var 'i' is escaped but it is
+                      // an actual error, since the pointer 'p' is increased.
+    *(p++);
+  }
+}
+
+void escape_after() {
+  int i = 0;
+  int j = 0;
+  int Limit = 10;
+
+  while (i < Limit) {
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: None of the condition variables (i, Limit) are updated in the loop body
+  }
+  int *p = &i;
+}
+
+int glob;
+void glob_var(int &x) {
+  int i = 0, Limit = 100;
+  while (x < Limit) { // Not an error since 'x' can be an alias of glob.
+    glob++;
+  }
+}
+
+void glob_var2() {
+  int i = 0, Limit = 100;
+  while (glob < Limit) { // Since 'glob' is declared out of the function we do not warn.
+    i++;
+  }
+}
+
+struct X {
+  void memberExpr_test(int i) {
+    while(i < m) { // False negative: No warning, since skipping the case where
+                   // a memberExpr can be found in the condition.
+      ;
+    }
+  }
+
+  void memberExpr_test2(int i) {
+    while(i < m) {
+      --m;
+    }
+  }
+  int m;
+};