Imported Upstream version 6.10.0.49

Former-commit-id: 1d6753294b2993e1fbf92de9366bb9544db4189b

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-accept.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-accept
+
+android-cloexec-accept
+======================
+
+The usage of ``accept()`` is not recommended, it's better to use ``accept4()``.
+Without this flag, an opened sensitive file descriptor would remain open across
+a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  accept(sockfd, addr, addrlen);
+
+  // becomes
+
+  accept4(sockfd, addr, addrlen, SOCK_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-accept4.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-accept4
+
+android-cloexec-accept4
+=======================
+
+``accept4()`` should include ``SOCK_CLOEXEC`` in its type argument to avoid the
+file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  accept4(sockfd, addr, addrlen, SOCK_NONBLOCK);
+
+  // becomes
+
+  accept4(sockfd, addr, addrlen, SOCK_NONBLOCK | SOCK_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-creat.rst

@@ -0,0 +1,16 @@
+.. title:: clang-tidy - android-cloexec-creat
+
+android-cloexec-creat
+=====================
+
+The usage of ``creat()`` is not recommended, it's better to use ``open()``.
+
+Examples:
+
+.. code-block:: c++
+
+  int fd = creat(path, mode);
+
+  // becomes
+
+  int fd = open(path, O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXEC, mode);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-dup.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-dup
+
+android-cloexec-dup
+===================
+
+The usage of ``dup()`` is not recommended, it's better to use ``fcntl()``,
+which can set the close-on-exec flag. Otherwise, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  int fd = dup(oldfd);
+
+  // becomes
+
+  int fd = fcntl(oldfd, F_DUPFD_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-epoll-create.rst

@@ -0,0 +1,17 @@
+.. title:: clang-tidy - android-cloexec-epoll-create
+
+android-cloexec-epoll-create
+============================
+
+The usage of ``epoll_create()`` is not recommended, it's better to use
+``epoll_create1()``, which allows close-on-exec.
+
+Examples:
+
+.. code-block:: c++
+
+  epoll_create(size);
+
+  // becomes
+
+  epoll_create1(EPOLL_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-epoll-create1.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-epoll-create1
+
+android-cloexec-epoll-create1
+=============================
+
+``epoll_create1()`` should include ``EPOLL_CLOEXEC`` in its type argument to
+avoid the file descriptor leakage. Without this flag, an opened sensitive file
+would remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  epoll_create1(0);
+
+  // becomes
+
+  epoll_create1(EPOLL_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-fopen.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-fopen
+
+android-cloexec-fopen
+=====================
+
+``fopen()`` should include ``e`` in their mode string; so ``re`` would be
+valid. This is equivalent to having set ``FD_CLOEXEC on`` that descriptor.
+
+Examples:
+
+.. code-block:: c++
+
+  fopen("fn", "r");
+
+  // becomes
+
+  fopen("fn", "re");
+

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-inotify-init.rst

@@ -0,0 +1,17 @@
+.. title:: clang-tidy - android-cloexec-inotify-init
+
+android-cloexec-inotify-init
+============================
+
+The usage of ``inotify_init()`` is not recommended, it's better to use
+``inotify_init1()``.
+
+Examples:
+
+.. code-block:: c++
+
+  inotify_init();
+
+  // becomes
+
+  inotify_init1(IN_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-inotify-init1.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-inotify-init1
+
+android-cloexec-inotify-init1
+=============================
+
+``inotify_init1()`` should include ``IN_CLOEXEC`` in its type argument to avoid the
+file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  inotify_init1(IN_NONBLOCK);
+
+  // becomes
+
+  inotify_init1(IN_NONBLOCK | IN_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-memfd-create.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-memfd-create
+
+android-cloexec-memfd-create
+============================
+
+``memfd_create()`` should include ``MFD_CLOEXEC`` in its type argument to avoid
+the file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  memfd_create(name, MFD_ALLOW_SEALING);
+
+  // becomes
+
+  memfd_create(name, MFD_ALLOW_SEALING | MFD_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-open.rst

@@ -0,0 +1,24 @@
+.. title:: clang-tidy - android-cloexec-open
+
+android-cloexec-open
+====================
+
+A common source of security bugs is code that opens a file without using the
+``O_CLOEXEC`` flag.  Without that flag, an opened sensitive file would remain
+open across a fork+exec to a lower-privileged SELinux domain, leaking that
+sensitive data. Open-like functions including ``open()``, ``openat()``, and
+``open64()`` should include ``O_CLOEXEC`` in their flags argument.
+
+Examples:
+
+.. code-block:: c++
+
+  open("filename", O_RDWR);
+  open64("filename", O_RDWR);
+  openat(0, "filename", O_RDWR);
+
+  // becomes
+
+  open("filename", O_RDWR | O_CLOEXEC);
+  open64("filename", O_RDWR | O_CLOEXEC);
+  openat(0, "filename", O_RDWR | O_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/android-cloexec-socket.rst

@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-socket
+
+android-cloexec-socket
+======================
+
+``socket()`` should include ``SOCK_CLOEXEC`` in its type argument to avoid the
+file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  socket(domain, type, SOCK_STREAM);
+
+  // becomes
+
+  socket(domain, type, SOCK_STREAM | SOCK_CLOEXEC);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/boost-use-to-string.rst

@@ -0,0 +1,22 @@
+.. title:: clang-tidy - boost-use-to-string
+
+boost-use-to-string
+===================
+
+This check finds conversion from integer type like ``int`` to ``std::string`` or
+``std::wstring`` using ``boost::lexical_cast``, and replace it with calls to
+``std::to_string`` and ``std::to_wstring``.
+
+It doesn't replace conversion from floating points despite the ``to_string``
+overloads, because it would change the behaviour.
+
+
+  .. code-block:: c++
+
+    auto str = boost::lexical_cast<std::string>(42);
+    auto wstr = boost::lexical_cast<std::wstring>(2137LL);
+
+    // Will be changed to
+    auto str = std::to_string(42);
+    auto wstr = std::to_wstring(2137LL);
+

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/bugprone-argument-comment.rst

@@ -0,0 +1,29 @@
+.. title:: clang-tidy - bugprone-argument-comment
+
+bugprone-argument-comment
+=========================
+
+Checks that argument comments match parameter names.
+
+The check understands argument comments in the form ``/*parameter_name=*/``
+that are placed right before the argument.
+
+.. code-block:: c++
+
+  void f(bool foo);
+
+  ...
+
+  f(/*bar=*/true);
+  // warning: argument name 'bar' in comment does not match parameter name 'foo'
+
+The check tries to detect typos and suggest automated fixes for them.
+
+Options
+-------
+
+.. option:: StrictMode
+
+   When zero (default value), the check will ignore leading and trailing
+   underscores and case when comparing names -- otherwise they are taken into
+   account.

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/bugprone-assert-side-effect.rst

@@ -0,0 +1,23 @@
+.. title:: clang-tidy - bugprone-assert-side-effect
+
+bugprone-assert-side-effect
+===========================
+
+Finds ``assert()`` with side effect.
+
+The condition of ``assert()`` is evaluated only in debug builds so a
+condition with side effect can cause different behavior in debug / release
+builds.
+
+Options
+-------
+
+.. option:: AssertMacros
+
+   A comma-separated list of the names of assert macros to be checked.
+
+.. option:: CheckFunctionCalls
+
+   Whether to treat non-const member and non-member functions as they produce
+   side effects. Disabled by default because it can increase the number of false
+   positive warnings.

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/bugprone-bool-pointer-implicit-conversion.rst

@@ -0,0 +1,16 @@
+.. title:: clang-tidy - bugprone-bool-pointer-implicit-conversion
+
+bugprone-bool-pointer-implicit-conversion
+=========================================
+
+Checks for conditions based on implicit conversion from a ``bool`` pointer to
+``bool``.
+
+Example:
+
+.. code-block:: c++
+
+  bool *p;
+  if (p) {
+    // Never used in a pointer-specific way.
+  }

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/bugprone-copy-constructor-init.rst

@@ -0,0 +1,29 @@
+.. title:: clang-tidy - bugprone-copy-constructor-init
+
+bugprone-copy-constructor-init
+==============================
+
+Finds copy constructors where the constructor doesn't call
+the copy constructor of the base class.
+
+.. code-block:: c++
+
+    class Copyable {
+    public:
+      Copyable() = default;
+      Copyable(const Copyable &) = default;
+    };
+    class X2 : public Copyable {
+      X2(const X2 &other) {} // Copyable(other) is missing
+    };
+
+Also finds copy constructors where the constructor of
+the base class don't have parameter.
+
+.. code-block:: c++
+
+    class X4 : public Copyable {
+      X4(const X4 &other) : Copyable() {} // other is missing
+    };
+
+The check also suggests a fix-its in some cases.

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst

@@ -0,0 +1,38 @@
+.. title:: clang-tidy - bugprone-dangling-handle
+
+bugprone-dangling-handle
+========================
+
+Detect dangling references in value handles like
+``std::experimental::string_view``.
+These dangling references can be a result of constructing handles from temporary
+values, where the temporary is destroyed soon after the handle is created.
+
+Examples:
+
+.. code-block:: c++
+
+  string_view View = string();  // View will dangle.
+  string A;
+  View = A + "A";  // still dangle.
+
+  vector<string_view> V;
+  V.push_back(string());  // V[0] is dangling.
+  V.resize(3, string());  // V[1] and V[2] will also dangle.
+
+  string_view f() {
+    // All these return values will dangle.
+    return string();
+    string S;
+    return S;
+    char Array[10]{};
+    return Array;
+  }
+
+Options
+-------
+
+.. option:: HandleClasses
+
+   A semicolon-separated list of class names that should be treated as handles.
+   By default only ``std::experimental::basic_string_view`` is considered.

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/bugprone-fold-init-type.rst

@@ -0,0 +1,27 @@
+.. title:: clang-tidy - bugprone-fold-init-type
+
+bugprone-fold-init-type
+=======================
+
+The check flags type mismatches in
+`folds <https://en.wikipedia.org/wiki/Fold_(higher-order_function)>`_
+like ``std::accumulate`` that might result in loss of precision.
+``std::accumulate`` folds an input range into an initial value using the type of
+the latter, with ``operator+`` by default. This can cause loss of precision
+through:
+
+- Truncation: The following code uses a floating point range and an int
+  initial value, so trucation wil happen at every application of ``operator+``
+  and the result will be `0`, which might not be what the user expected.
+
+.. code-block:: c++
+
+  auto a = {0.5f, 0.5f, 0.5f, 0.5f};
+  return std::accumulate(std::begin(a), std::end(a), 0);
+
+- Overflow: The following code also returns `0`.
+
+.. code-block:: c++
+
+  auto a = {65536LL * 65536 * 65536};
+  return std::accumulate(std::begin(a), std::end(a), 0);

external/llvm-project/clang-tools-extra/docs/clang-tidy/checks/bugprone-forward-declaration-namespace.rst

@@ -0,0 +1,20 @@
+.. title:: clang-tidy - bugprone-forward-declaration-namespace
+
+bugprone-forward-declaration-namespace
+======================================
+
+Checks if an unused forward declaration is in a wrong namespace.
+
+The check inspects all unused forward declarations and checks if there is any
+declaration/definition with the same name existing, which could indicate that
+the forward declaration is in a potentially wrong namespace.
+
+.. code-block:: c++
+
+  namespace na { struct A; }
+  namespace nb { struct A {}; }
+  nb::A a;
+  // warning : no definition found for 'A', but a definition with the same name
+  // 'A' found in another namespace 'nb::'
+
+This check can only generate warnings, but it can't suggest a fix at this point.