[clang-tidy] WIP implement cppcoreguidelines check for mixed integer arithmetic

[JonasToth]

Summary

This check implements rules ES.100 and ES.102 of the CppCoreGuidelines
forbidding to mix signed and unsigned integer types in arithmetic expression.

It currently functions for the "normal" arithmetic but when implicit casts
to its happen for short and char i have no idea how to implement that
properly. Here some advice would be really helpful.

[JonasToth]

• [Misc] remove iostream

[Eugene.Zelenko]

docs/ReleaseNotes.rst

131

I think will be good idea to shorten description to one sentence and also make first sentence in documentation same.

[aaron.ballman]

The "enforcement" listed on the C++ Core Guidelines is very unhelpful, so it might be worth bringing it up as an issue on their bug tracker. ES.100 basically says "you know what we mean, wink wink" as enforcement and doesn't give any guidance as to what is safe or unsafe. It gives no exceptions, which I think is unlikely to be useful to most developers. For instance: void f(unsigned i) { if (i > 0) {} }, this is a mixed signed and unsigned comparison (literals are signed by default) -- should this check diagnose? How about unsigned int i = 12; i += 1;? ES.102 is equally as strange with "Flag unsigned literals (e.g. -2) used as container subscripts." That's a signed literal (2) with a negation operator -- do they mean "Flag container subscripts whose value is known to be negative", or something else?

clang-tidy/cppcoreguidelines/MixedIntArithmeticCheck.cpp

32

What about % or comparisons operators?

test/clang-tidy/cppcoreguidelines-mixed-int-arithmetic.cpp

168–169

I think these are intended to be flagged under ES.102. "Flag results of unsigned arithmetic assigned to or printed as signed."

[JonasToth]

The "enforcement" listed on the C++ Core Guidelines is very unhelpful, so it might be worth bringing it up as an issue on their bug tracker. ES.100 basically says "you know what we mean, wink wink" as enforcement and doesn't give any guidance as to what is safe or unsafe. It gives no exceptions, which I think is unlikely to be useful to most developers. For instance: void f(unsigned i) { if (i > 0) {} }, this is a mixed signed and unsigned comparison (literals are signed by default) -- should this check diagnose?

I think the guidelines mostly aim for actual calculations here. For ES.102 there is an exception to "we want actual modulo arithmetic". They seem mostly concerned with the mixing of the signedness of integer types that comes from explicitly expressing non-negative values with unsigned types. Because this is a common pattern (e.g. STL containers), the mixing from literals and co is quickly overseen.
See ES.106: Don’t try to avoid negative values by using unsigned

How about unsigned int i = 12; i += 1;? ES.102 is equally as strange with "Flag unsigned literals (e.g. -2) used as container subscripts." That's a signed literal (2) with a negation operator -- do they mean "Flag container subscripts whose value is known to be negative", or something else?

I think here ES.106 is again the rationale but your example shows a hole. unsigned int i = -1 is explicitly forbidden and the example shows a chain of implicit conversion of integer types as bad code.

My gut feeling is that the guidelines want programers to write auto i = 12u or unsigned int = 12u but they are not clear about that. Other rules that could relate to this are:
ES.11: Use auto to avoid redundant repetition of type names, ES.23: Prefer the {} initializer syntax (forbidding implicit conversions in initialization), ES.48: Avoid casts (maybe, but implicit conversion are not covered there).

I will ask them about this issue and hopefully we have some clarification. But I didn't have much success before :D

@aaron.ballman You are a maintainer for the cert rules, are you? How do you handle these common issues with integer types? Maybe we could already propose some guidance based on cert. It is mentioned as well written standard in the guidelines :)

clang-tidy/cppcoreguidelines/MixedIntArithmeticCheck.cpp

32

I forgot %. Comparing signed and unsigned should be covered by front-end warnings (-Wsign-compare)

test/clang-tidy/cppcoreguidelines-mixed-int-arithmetic.cpp

168–169

Yes they are but that was unintended :)

I should add a new section for such cases and include some logic in the matchers for it.

[aaron.ballman]

In D40854#950640, @JonasToth wrote:

The "enforcement" listed on the C++ Core Guidelines is very unhelpful, so it might be worth bringing it up as an issue on their bug tracker. ES.100 basically says "you know what we mean, wink wink" as enforcement and doesn't give any guidance as to what is safe or unsafe. It gives no exceptions, which I think is unlikely to be useful to most developers. For instance: void f(unsigned i) { if (i > 0) {} }, this is a mixed signed and unsigned comparison (literals are signed by default) -- should this check diagnose?

I think the guidelines mostly aim for actual calculations here. For ES.102 there is an exception to "we want actual modulo arithmetic". They seem mostly concerned with the mixing of the signedness of integer types that comes from explicitly expressing non-negative values with unsigned types. Because this is a common pattern (e.g. STL containers), the mixing from literals and co is quickly overseen.
See ES.106: Don’t try to avoid negative values by using unsigned

How about unsigned int i = 12; i += 1;? ES.102 is equally as strange with "Flag unsigned literals (e.g. -2) used as container subscripts." That's a signed literal (2) with a negation operator -- do they mean "Flag container subscripts whose value is known to be negative", or something else?

I think here ES.106 is again the rationale but your example shows a hole. unsigned int i = -1 is explicitly forbidden and the example shows a chain of implicit conversion of integer types as bad code.

My gut feeling is that the guidelines want programers to write auto i = 12u or unsigned int = 12u but they are not clear about that. Other rules that could relate to this are:
ES.11: Use auto to avoid redundant repetition of type names, ES.23: Prefer the {} initializer syntax (forbidding implicit conversions in initialization), ES.48: Avoid casts (maybe, but implicit conversion are not covered there).

I will ask them about this issue and hopefully we have some clarification. But I didn't have much success before :D

Thanks! As it stands, I'm not able to determine whether your implementation actually does or does not enforce those rules. That's why I was wondering what the extent of the coverage is according to the rule authors, because I am not certain whether we're actually implementing the intent of the rules or not.

@aaron.ballman You are a maintainer for the cert rules, are you? How do you handle these common issues with integer types? Maybe we could already propose some guidance based on cert. It is mentioned as well written standard in the guidelines :)

Yes, I used to maintain the CERT rules when I worked for the SEI (and I authored a considerable number of them). CERT and the C++ Core Guidelines have a somewhat fundamental difference in opinion on how we write the rules. CERT flags things that are demonstrably going to lead to incorrectness (specifically, vulnerabilities). The C++ Core Guidelines flag things that could possibly lead to correctness issues but may also be perfectly correct code. Because of this difference, CERT rules are a bit harder to implement in clang-tidy because they often will have some component of data or flow analysis to them, while C++ Core Guidelines are often blanket bans.

That said, CERT's guidance on integers mostly falls back to the C rules: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152052

I would recommend looking at the C++ Core Guideline wording and try to come up with example code that would run afoul of the rule to see if *you* think a diagnostic would be useful with that code. If you can't convince yourself that diagnosing the code is a good idea, it's worth bringing up to the authors to see if they agree. Similarly, see if you can find example code that would not run afoul of the rules but you think *should* to see if they agree. (You can use the CERT rules on integers to help give ideas.) Once you have a corpus of examples you want to see diagnosed and not diagnosed, try to devise (possibly new) wording for the enforcement section of the rule and see if the rule authors agree with the enforcement. From there, writing the check becomes a pretty simple exercise in translating the enforcement into a clang-tidy check.

[JonasToth]

Guidelines issue is here: https://github.com/isocpp/CppCoreGuidelines/issues/1120

[JonasToth]

• rebase after release of 6.0

[JonasToth]

rebase to 7.0.0

[JonasToth]

The guideline authors will focus on mixing integer length and integer signdness.

Thank you for the suggestion! Per our editor's discussion, we agree with "If one then mixes integer lengths and signedness in calculations confusion on what happens might occur" and would like to focus the discussion there.
signed and unsigned are defined in the standard and we cannot quibble with those but we can discuss mixed arithmetic. We should consider this separately.

Bjarne will add some text to this item.

[JonasToth]

• update to trunk
• [Doc] update to new doc style

[JonasToth]

• get check up to date

[JonasToth]

• Merge branch 'master' into check_mixed_arithmetic

[JonasToth]

• Merge branch 'master' into check_mixed_arithmetic, a lot has happened...

[JonasToth]

• avoid bitrot

[MyDeveloperDay]

clang-tidy/cppcoreguidelines/MixedIntArithmeticCheck.h

2

I guess the license has to be updated

docs/ReleaseNotes.rst

216

remove

docs/clang-tidy/checks/cppcoreguidelines-mixed-int-arithmetic.rst

12

probably needs running though validate_check.py from { D55523} to make this 80 chars wide

clang-tidy/cppcoreguidelines/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangTidyCppCoreGuidelinesModule
   CppCoreGuidelinesTidyModule.cpp
   InterfacesGlobalInitCheck.cpp
+  MixedIntArithmeticCheck.cpp
   NoMallocCheck.cpp
   OwningMemoryCheck.cpp
   ProBoundsArrayToPointerDecayCheck.cpp
   ProBoundsConstantArrayIndexCheck.cpp
   ProBoundsPointerArithmeticCheck.cpp
   ProTypeConstCastCheck.cpp
   ProTypeCstyleCastCheck.cpp
   ProTypeMemberInitCheck.cpp

clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp

 //===--- CppCoreGuidelinesModule.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 "../misc/UnconventionalAssignOperatorCheck.h"
 #include "InterfacesGlobalInitCheck.h"
+#include "MixedIntArithmeticCheck.h"
 #include "NoMallocCheck.h"
 #include "OwningMemoryCheck.h"
 #include "ProBoundsArrayToPointerDecayCheck.h"
 #include "ProBoundsConstantArrayIndexCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
 #include "ProTypeCstyleCastCheck.h"
 #include "ProTypeMemberInitCheck.h"

 namespace cppcoreguidelines {
 
 /// A module containing checks of the C++ Core Guidelines
 class CppCoreGuidelinesModule : public ClangTidyModule {
 public:
   void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
     CheckFactories.registerCheck<InterfacesGlobalInitCheck>(
         "cppcoreguidelines-interfaces-global-init");
+    CheckFactories.registerCheck<MixedIntArithmeticCheck>(
+        "cppcoreguidelines-mixed-int-arithmetic");
     CheckFactories.registerCheck<NoMallocCheck>("cppcoreguidelines-no-malloc");
     CheckFactories.registerCheck<OwningMemoryCheck>(
         "cppcoreguidelines-owning-memory");
     CheckFactories.registerCheck<ProBoundsArrayToPointerDecayCheck>(
         "cppcoreguidelines-pro-bounds-array-to-pointer-decay");
     CheckFactories.registerCheck<ProBoundsConstantArrayIndexCheck>(
         "cppcoreguidelines-pro-bounds-constant-array-index");
     CheckFactories.registerCheck<ProBoundsPointerArithmeticCheck>(

clang-tidy/cppcoreguidelines/MixedIntArithmeticCheck.h

+//===--- MixedIntArithmeticCheck.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_CPPCOREGUIDELINES_MIXED_INT_ARITHMETIC_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_MIXED_INT_ARITHMETIC_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace cppcoreguidelines {
+
+/// Find places that use unsigned integers in arithmetic expressions.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-mixed-int-arithmetic.html
+class MixedIntArithmeticCheck : public ClangTidyCheck {
+public:
+  MixedIntArithmeticCheck(StringRef Name, ClangTidyContext *Context)
+      : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+};
+
+} // namespace cppcoreguidelines
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_MIXED_INT_ARITHMETIC_H

clang-tidy/cppcoreguidelines/MixedIntArithmeticCheck.cpp

+//===--- MixedIntArithmeticCheck.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 "MixedIntArithmeticCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+#include <iostream>
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace cppcoreguidelines {
+
+void MixedIntArithmeticCheck::registerMatchers(MatchFinder *Finder) {
+  const auto UnsignedIntegerOperand =
+      expr(ignoringImpCasts(hasType(isUnsignedInteger())))
+          .bind("unsigned-binary-operand");
+  const auto SignedIntegerOperand =
+      expr(ignoringImpCasts(hasType(isSignedInteger())))
+          .bind("signed-binary-operand");
+
+  // Match integer arithmetic mixing signed and unsigned types.
+  Finder->addMatcher(
+      binaryOperator(allOf(anyOf(hasOperatorName("+"), hasOperatorName("-"),
+                                 hasOperatorName("*"), hasOperatorName("/")),
+                           hasEitherOperand(UnsignedIntegerOperand),
+                           hasEitherOperand(SignedIntegerOperand),
+                           hasRHS(hasType(isInteger())),
+                           hasLHS(hasType(isInteger()))))
+          .bind("mixed-binary-arithmetic"),
+      this);
+}
+
+void MixedIntArithmeticCheck::check(const MatchFinder::MatchResult &Result) {
+  const auto *UnsignedOperand =
+      Result.Nodes.getNodeAs<Expr>("unsigned-binary-operand");
+  const auto *SignedOperand =
+      Result.Nodes.getNodeAs<Expr>("signed-binary-operand");
+  const auto *MixedArithmetic =
+      Result.Nodes.getNodeAs<BinaryOperator>("mixed-binary-arithmetic");
+
+  assert(UnsignedOperand && MixedArithmetic &&
+         "Matcher did not match operand and operation");
+
+  diag(MixedArithmetic->getLocStart(),
+       "mixed signed and unsigned arithmetic; "
+       "prefer signed integers and use unsigned types only for modulo "
+       "arithmetic")
+      << MixedArithmetic->getSourceRange();
+
+  diag(SignedOperand->getLocStart(), "signed operand", DiagnosticIDs::Note)
+      << SignedOperand->getSourceRange();
+  diag(UnsignedOperand->getLocStart(), "unsigned operand", DiagnosticIDs::Note)
+      << UnsignedOperand->getSourceRange();
+}
+
+} // namespace cppcoreguidelines
+} // namespace tidy
+} // namespace clang

docs/ReleaseNotes.rst

- New `bugprone-misplaced-operator-in-strlen-in-alloc
   <http://clang.llvm.org/extra/clang-tidy/checks/bugprone-misplaced-operator-in-strlen-in-alloc.html>`_ check
 
   Finds cases where ``1`` is added to the string in the argument to
   ``strlen()``, ``strnlen()``, ``strnlen_s()``, ``wcslen()``, ``wcsnlen()``, and
   ``wcsnlen_s()`` instead of the result and the value is used as an argument to
   a memory allocation function (``malloc()``, ``calloc()``, ``realloc()``,
   ``alloca()``) or the ``new[]`` operator in `C++`.
 
+- New `cppcoreguidelines-mixed-int-arithmetic
+  <http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-mixed-int-arithmetic.html>`_ check
+
+  Finds cases where unsigned and signed integers are used together in arithmetic expressions.
+  Unsigned integers wrap to 0 when overflowing while the behaviour of signed integers
+  is undefined in this case. The combination leads to possibly unexpected results.
+
 - New `cppcoreguidelines-owning-memory <http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html>`_ check 
 
   This check implements the type-based semantic of ``gsl::owner<T*>``, but without
   flow analysis.
 
 - New `fuchsia-default-arguments
   <http://clang.llvm.org/extra/clang-tidy/checks/fuchsia-default-arguments.html>`_ check
 

 
 - The 'misc-fold-init-type' check was renamed to `bugprone-fold-init-type
   <http://clang.llvm.org/extra/clang-tidy/checks/bugprone-fold-init-type.html>`_
 
 - The 'misc-forward-declaration-namespace' check was renamed to `bugprone-forward-declaration-namespace
   <http://clang.llvm.org/extra/clang-tidy/checks/bugprone-forward-declaration-namespace.html>`_
 
 - The 'misc-inaccurate-erase' check was renamed to `bugprone-inaccurate-erase
   <http://clang.llvm.org/extra/clang-tidy/checks/bugprone-inaccurate-erase.html>`_
 
 - The 'misc-inefficient-algorithm' check was renamed to `performance-inefficient-algorithm
   <http://clang.llvm.org/extra/clang-tidy/checks/performance-inefficient-algorithm.html>`_
 
 - The 'misc-move-const-arg' check was renamed to `performance-move-const-arg
   <http://clang.llvm.org/extra/clang-tidy/checks/performance-move-const-arg.html>`_
 
 - The 'misc-move-constructor-init' check was renamed to `performance-move-constructor-init

docs/clang-tidy/checks/cppcoreguidelines-mixed-int-arithmetic.rst

+.. title:: clang-tidy - cppcoreguidelines-mixed-int-arithmetic
+
+cppcoreguidelines-mixed-int-arithmetic
+======================================
+
+This check enforces `ES. 100 <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es100-dont-mix-signed-and-unsigned-arithmetic>`_
+and `ES. 102 <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es102-use-signed-types-for-arithmetic>`_
+of the `CppCoreGuidelines <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c-core-guidelines>`_
+addressing the use of unsigned types in integer arithmetic.
+
+Because of the subtile difference between ``signed`` and ``unsigned`` integer
+types in C++ it is recommended to use ``signed`` types in general for arithmetic
+and to not mix ``signed`` and ``unsigned`` integers in arithmetic expressions.
+
+The behaviour of ``signed`` integer type is undefined when an overflow occurs.
+On the contrary ``unsigned`` types will wrap around leading to potentially
+unexpected results of integer computations.
+
+.. code-block:: c++
+
+    // Taken from the CppCoreGuidelines
+    template<typename T, typename T2>
+    T subtract(T x, T2 y)
+    {
+        return x - y;
+    }
+
+    void test()
+    {
+        int s = 5;
+        unsigned int us = 5;
+        cout << subtract(s, 7) << '\n';       // -2
+        cout << subtract(us, 7u) << '\n';     // 4294967294
+        cout << subtract(s, 7u) << '\n';      // -2
+        cout << subtract(us, 7) << '\n';      // 4294967294
+        cout << subtract(s, us + 2) << '\n';  // -2
+        cout << subtract(us, s + 2) << '\n';  // 4294967294
+    }

docs/clang-tidy/checks/list.rst

.. toctree::
    cert-err61-cpp (redirects to misc-throw-by-value-catch-by-reference) <cert-err61-cpp>
    cert-fio38-c (redirects to misc-non-copyable-objects) <cert-fio38-c>
    cert-flp30-c
    cert-msc30-c (redirects to cert-msc50-cpp) <cert-msc30-c>
    cert-msc50-cpp
    cert-oop11-cpp (redirects to performance-move-constructor-init) <cert-oop11-cpp>
    cppcoreguidelines-c-copy-assignment-signature (redirects to misc-unconventional-assign-operator) <cppcoreguidelines-c-copy-assignment-signature>
    cppcoreguidelines-interfaces-global-init
+   cppcoreguidelines-mixed-int-arithmetic
    cppcoreguidelines-no-malloc
    cppcoreguidelines-owning-memory
    cppcoreguidelines-pro-bounds-array-to-pointer-decay
    cppcoreguidelines-pro-bounds-constant-array-index
    cppcoreguidelines-pro-bounds-pointer-arithmetic
    cppcoreguidelines-pro-type-const-cast
    cppcoreguidelines-pro-type-cstyle-cast
    cppcoreguidelines-pro-type-member-init

test/clang-tidy/cppcoreguidelines-mixed-int-arithmetic.cpp

+// RUN: %check_clang_tidy %s cppcoreguidelines-mixed-int-arithmetic %t
+
+enum UnsignedEnum : unsigned char {
+  UEnum1,
+  UEnum2
+};
+
+enum SignedEnum : signed char {
+  SEnum1,
+  SEnum2
+};
+
+unsigned char returnUnsignedCharacter() { return 42; }
+unsigned returnUnsignedNumber() { return 42u; }
+long returnBigNumber() { return 42; }
+float unrelatedThing() { return 42.f; }
+SignedEnum returnSignedEnum() { return SEnum1; }
+UnsignedEnum returnUnsignedEnum() { return UEnum1; }
+
+void mixed_binary() {
+  unsigned int UInt1 = 42;
+  signed int SInt1 = 42;
+  UnsignedEnum UE1 = UEnum1;
+  SignedEnum SE1 = SEnum1;
+  float UnrelatedFloat = 42.f;
+
+  // Test traditional integer types.
+  auto R1 = UInt1 + SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:21: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  int R2 = UInt1 - SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:20: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:12: note: unsigned operand
+
+  unsigned int R3 = UInt1 * SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:29: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:21: note: unsigned operand
+
+  unsigned int R4 = UInt1 / returnBigNumber();
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:29: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:21: note: unsigned operand
+
+  char R5 = returnUnsignedCharacter() + SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:41: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  auto R6 = SInt1 - 10u;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:13: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:21: note: unsigned operand
+
+  auto R7 = UInt1 * 10;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:21: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  auto R8 = 10u / returnBigNumber();
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:19: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  auto R9 = 10 + returnUnsignedCharacter();
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:13: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:18: note: unsigned operand
+
+  // Test enum types.
+  char R10 = returnUnsignedEnum() - SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:37: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:14: note: unsigned operand
+
+  unsigned char R11 = returnSignedEnum() * UInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:23: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:23: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:44: note: unsigned operand
+
+  char R12 = UE1 / SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:20: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:14: note: unsigned operand
+
+  unsigned char R13 = SE1 + UInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:23: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:23: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:29: note: unsigned operand
+
+  auto R14 = SE1 - 10u;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:14: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:20: note: unsigned operand
+
+  auto R15 = UE1 * 10;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:20: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:14: note: unsigned operand
+
+  auto R16 = returnSignedEnum() / 10u;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:14: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:35: note: unsigned operand
+
+  auto R17 = returnUnsignedEnum() + 10;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:37: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:14: note: unsigned operand
+
+  // Check that floating pointer numbers do not interfere improperly.
+  // Implicit conversion from float to int are covered in other checks.
+  int Ok1 = UInt1 + UnrelatedFloat;
+  unsigned int Ok2 = SInt1 - UnrelatedFloat;
+  int Ok3 = UInt1 * unrelatedThing();
+  unsigned int Ok4 = SInt1 / unrelatedThing();
+  auto Ok5 = 10 + UnrelatedFloat;
+  auto Ok6 = 10u - UnrelatedFloat;
+}
+
+void mixed_assignments() {
+}
+
+void pure_unsigned() {
+  unsigned int UInt1 = 42u;
+  unsigned char UChar1 = 42u;
+  UnsignedEnum UE1 = UEnum1;
+  float UnrelatedFloat = 42.f;
+
+  auto Ok1 = UInt1 + UChar1;
+  auto Ok2 = UChar1 + UInt1;
+  auto Ok3 = UInt1 + returnUnsignedCharacter();
+  auto Ok4 = UChar1 + returnUnsignedCharacter();
+  auto Ok5 = returnUnsignedCharacter() + returnUnsignedCharacter();
+  auto Ok6 = UInt1 + UE1;
+  auto Ok7 = UInt1 + returnUnsignedEnum();
+  auto Ok8 = UE1 + UE1;
+  // FIXME: unsigned character converts to 'int' and pollutes the result.
+  // http://en.cppreference.com/w/cpp/language/implicit_conversion  Integral conversions
+  // if `returnUnsignedCharacter()` would return char, the conversion would result
+  // in either `signed int` or `unsigned int` (arch dependent i guess). Both `short`
+  // and `char` perform this conversion in arithmetic operations. This would probably
+  // need some bigger magic to match in the AST, but should be possible in theory.
+  auto Ok9 = 10u * (returnUnsignedNumber() + returnUnsignedEnum());
+  auto Ok10 = 10u * (10u + 10ul);
+  auto Ok11 = 10u * (10u + returnUnsignedEnum());
+  auto Ok12 = returnUnsignedCharacter() * (10u + returnUnsignedEnum());
+
+  // Test that unrelated types do not interfere.
+  auto OkUnrelated1 = UInt1 + UnrelatedFloat;
+  auto OkUnrelated2 = UChar1 + unrelatedThing();
+  auto OkUnrelated3 = UE1 + UnrelatedFloat;
+  auto OkUnrelated4 = UE1 + unrelatedThing();
+
+  // Test that correct assignments to not cause warnings.
+  UInt1 += 1u;
+  UInt1 -= returnUnsignedCharacter();
+  UInt1 *= UE1;
+  UInt1 /= returnUnsignedEnum();
+  UInt1 += (returnUnsignedCharacter() + returnUnsignedEnum());
+}
+
+void pure_signed() {
+  int SInt1 = 42u;
+  signed char SChar1 = 42u;
+  SignedEnum SE1 = SEnum1;
+
+  float UnrelatedFloat = 42.f;
+
+  auto Ok1 = SInt1 + SChar1;
+  auto Ok2 = SChar1 + SInt1;
+  auto Ok3 = SInt1 + returnBigNumber();
+  auto Ok4 = SChar1 + returnBigNumber();
+  auto Ok5 = returnBigNumber() + returnBigNumber();
+  auto Ok6 = SInt1 + SE1;
+  auto Ok7 = SInt1 + returnSignedEnum();
+  auto Ok8 = SE1 + SE1;
+  auto Ok9 = 10 * (returnBigNumber() + returnSignedEnum());
+
+  // Test that unrelated types do not interfere.
+  auto OkUnrelated1 = SInt1 + UnrelatedFloat;
+  auto OkUnrelated2 = SChar1 + unrelatedThing();
+  auto OkUnrelated3 = SE1 + UnrelatedFloat;
+  auto OkUnrelated4 = SE1 + unrelatedThing();
+}