[all-commits] [llvm/llvm-project] 46b8ea: [clang-tidy] Add check for implicit widening of mu...

[Roman Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 46b8ea2fff90b44b7ae558999721cf30f9b83aa9
      https://github.com/llvm/llvm-project/commit/46b8ea2fff90b44b7ae558999721cf30f9b83aa9
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2021-04-13 (Tue, 13 Apr 2021)

  Changed paths:
    M clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
    M clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
    A clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp
    A clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.h
    M clang-tools-extra/docs/ReleaseNotes.rst
    A clang-tools-extra/docs/clang-tidy/checks/bugprone-implicit-widening-of-multiplication-result.rst
    M clang-tools-extra/docs/clang-tidy/checks/list.rst
    A clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-array-subscript-expression.cpp
    A clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-char.cpp
    A clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-extint.cpp
    A clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-int.cpp
    A clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-pointer-offset.cpp
    A clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-short.cpp
    M clang/include/clang/AST/ASTContext.h
    M clang/lib/AST/ASTContext.cpp

  Log Message:
  -----------
  [clang-tidy] Add check for implicit widening of multiplication result

Overflows are never fun.
In most cases (in most of the code), they are rare,
because usually you e.g. don't have as many elements.

However, it's exceptionally easy to fall into this pitfail
in code that deals with images, because, assuming 4-channel 32-bit FP data,
you need *just* ~269 megapixel image to case an overflow
when computing at least the total byte count.

In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs:
* https://github.com/darktable-org/darktable/pull/7740
* https://github.com/darktable-org/darktable/pull/7419
* https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c
* https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28
* https://github.com/darktable-org/darktable/pull/670
* https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583

and yet they clearly keep resurfacing still.

It would be immensely helpful to have a diagnostic for those patterns,
which is what this change proposes.

Currently, i only diagnose the most obvious case, where multiplication
is directly widened with no other expressions inbetween,
(i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`)
however that might be worth relaxing later.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D93822