llvmorg-github-actions[bot] wrote:
<!--LLVM PR SUMMARY COMMENT--> @llvm/pr-subscribers-clang-tidy Author: Zeyi Xu (zeyi2) <details> <summary>Changes</summary> Tracking issue: #<!-- -->201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is the mechanical rename for part 2/4 of the remaining bugprone check documentation. The rewrite is provided by the next PR in this stack. --- <sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub> --- Patch is 96.87 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/214418.diff 36 Files Affected: - (renamed) clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.md (+38-38) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.md (+48) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst (-48) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.md (+34) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst (-34) - (renamed) clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.md (+12-12) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.md (+39) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst (-39) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.md (+82) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst (-84) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/lambda-function-name.md (+38) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/lambda-function-name.rst (-35) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/misleading-setter-of-reference.md (+47) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/misleading-setter-of-reference.rst (-46) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.md (+53) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-operator-in-strlen-in-alloc.rst (-57) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-widening-cast.md (+62) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/misplaced-widening-cast.rst (-65) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/missing-end-comparison.md (+89) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/missing-end-comparison.rst (-91) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/move-forwarding-reference.md (+58) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/move-forwarding-reference.rst (-60) - (renamed) clang-tools-extra/docs/clang-tidy/checks/bugprone/multi-level-implicit-pointer-conversion.md (+23-24) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.md (+99) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/multiple-new-in-one-expression.rst (-99) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.md (+126) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/narrowing-conversions.rst (-127) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.md (+51) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/non-zero-enum-to-bool-conversion.rst (-53) - (renamed) clang-tools-extra/docs/clang-tidy/checks/bugprone/nondeterministic-pointer-iteration-order.md (+22-24) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.md (+125) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/not-null-terminated-result.rst (-134) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/optional-value-conversion.md (+75) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/optional-value-conversion.rst (-76) - (added) clang-tools-extra/docs/clang-tidy/checks/bugprone/pointer-arithmetic-on-polymorphic-object.md (+65) - (removed) clang-tools-extra/docs/clang-tidy/checks/bugprone/pointer-arithmetic-on-polymorphic-object.rst (-68) ``````````diff diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.md similarity index 52% rename from clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst rename to clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.md index f3f0331b15b5e..9231cb6f2e844 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/inc-dec-in-conditions.md @@ -1,7 +1,7 @@ -.. title:: clang-tidy - bugprone-inc-dec-in-conditions +```{title} clang-tidy - bugprone-inc-dec-in-conditions +``` -bugprone-inc-dec-in-conditions -============================== +# bugprone-inc-dec-in-conditions Detects when a variable is both incremented/decremented and referenced inside a complex condition and suggests moving them outside to avoid ambiguity in the @@ -12,57 +12,57 @@ to unexpected behavior. The side-effect of changing the variable's value within the condition can make the code difficult to reason about. Additionally, the developer's intended timing for the modification of the variable may not be clear, leading to misunderstandings and errors. This can be particularly -problematic when the condition involves logical operators like ``&&`` and -``||``, where the order of evaluation can further complicate the situation. +problematic when the condition involves logical operators like `&&` and +`||`, where the order of evaluation can further complicate the situation. Consider the following example: -.. code-block:: c++ - - int i = 0; - // ... - if (i++ < 5 && i > 0) { - // do something - } +```c++ +int i = 0; +// ... +if (i++ < 5 && i > 0) { + // do something +} +``` In this example, the result of the expression may not be what the developer -intended. The original intention of the developer could be to increment ``i`` +intended. The original intention of the developer could be to increment `i` after the entire condition is evaluated, but in reality, i will be incremented -before ``i > 0`` is executed. This can lead to unexpected behavior and bugs in +before `i > 0` is executed. This can lead to unexpected behavior and bugs in the code. To fix this issue, the developer should separate the increment operation from the condition and perform it separately. For example, they can -increment ``i`` in a separate statement before or after the condition is -evaluated. This ensures that the value of ``i`` is predictable and consistent +increment `i` in a separate statement before or after the condition is +evaluated. This ensures that the value of `i` is predictable and consistent throughout the code. -.. code-block:: c++ - - int i = 0; - // ... - i++; - if (i <= 5 && i > 0) { - // do something - } +```c++ +int i = 0; +// ... +i++; +if (i <= 5 && i > 0) { + // do something +} +``` Another common issue occurs when multiple increments or decrements are performed on the same variable inside a complex condition. For example: -.. code-block:: c++ - - int i = 4; - // ... - if (i++ < 5 || --i > 2) { - // do something - } +```c++ +int i = 4; +// ... +if (i++ < 5 || --i > 2) { + // do something +} +``` There is a potential issue with this code due to the order of evaluation in -C++. The ``||`` operator used in the condition statement guarantees that if -the first operand evaluates to ``true``, the second operand will not be -evaluated. This means that if ``i`` were initially ``4``, the first operand -``i < 5`` would evaluate to ``true`` and the second operand ``i > 2`` would -not be evaluated. As a result, the decrement operation ``--i`` would not be -executed and ``i`` would hold value ``5``, which may not be the intended +C++. The `||` operator used in the condition statement guarantees that if +the first operand evaluates to `true`, the second operand will not be +evaluated. This means that if `i` were initially `4`, the first operand +`i < 5` would evaluate to `true` and the second operand `i > 2` would +not be evaluated. As a result, the decrement operation `--i` would not be +executed and `i` would hold value `5`, which may not be the intended behavior for the developer. To avoid this potential issue, the both increment and decrement operation on -``i`` should be moved outside the condition statement. +`i` should be moved outside the condition statement. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.md new file mode 100644 index 0000000000000..a054d0cf80f47 --- /dev/null +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.md @@ -0,0 +1,48 @@ +```{title} clang-tidy - bugprone-incorrect-enable-if +``` + +# bugprone-incorrect-enable-if + +Detects incorrect usages of `std::enable_if` that don't name the nested +`type` type. + +In C++11 introduced `std::enable_if` as a convenient way to leverage SFINAE. +One form of using `std::enable_if` is to declare an unnamed template type +parameter with a default type equal to +`typename std::enable_if<condition>::type`. If the author forgets to name +the nested type `type`, then the code will always consider the candidate +template even if the condition is not met. + +Below are some examples of code using `std::enable_if` correctly and +incorrect examples that this check flags. + +```c++ +template <typename T, typename = typename std::enable_if<T::some_trait>::type> +void valid_usage() { ... } + +template <typename T, typename = std::enable_if_t<T::some_trait>> +void valid_usage_with_trait_helpers() { ... } + +// The below code is not a correct application of SFINAE. Even if +// T::some_trait is not true, the function will still be considered in the +// set of function candidates. It can either incorrectly select the function +// when it should not be a candidates, and/or lead to hard compile errors +// if the body of the template does not compile if the condition is not +// satisfied. +template <typename T, typename = std::enable_if<T::some_trait>> +void invalid_usage() { ... } + +// The tool suggests the following replacement for 'invalid_usage': +template <typename T, typename = typename std::enable_if<T::some_trait>::type> +void fixed_invalid_usage() { ... } +``` + +C++14 introduced the trait helper `std::enable_if_t` which reduces the +likelihood of this error. C++20 introduces constraints, which generally +supersede the use of `std::enable_if`. See +{doc}`modernize-type-traits <../modernize/type-traits>` for another tool +that will replace `std::enable_if` with +`std::enable_if_t`, and see +{doc}`modernize-use-constraints <../modernize/use-constraints>` for another +tool that replaces `std::enable_if` with C++20 constraints. Consider these +newer mechanisms where possible. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst deleted file mode 100644 index a7860a96e3081..0000000000000 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. title:: clang-tidy - bugprone-incorrect-enable-if - -bugprone-incorrect-enable-if -============================ - -Detects incorrect usages of ``std::enable_if`` that don't name the nested -``type`` type. - -In C++11 introduced ``std::enable_if`` as a convenient way to leverage SFINAE. -One form of using ``std::enable_if`` is to declare an unnamed template type -parameter with a default type equal to -``typename std::enable_if<condition>::type``. If the author forgets to name -the nested type ``type``, then the code will always consider the candidate -template even if the condition is not met. - -Below are some examples of code using ``std::enable_if`` correctly and -incorrect examples that this check flags. - -.. code-block:: c++ - - template <typename T, typename = typename std::enable_if<T::some_trait>::type> - void valid_usage() { ... } - - template <typename T, typename = std::enable_if_t<T::some_trait>> - void valid_usage_with_trait_helpers() { ... } - - // The below code is not a correct application of SFINAE. Even if - // T::some_trait is not true, the function will still be considered in the - // set of function candidates. It can either incorrectly select the function - // when it should not be a candidates, and/or lead to hard compile errors - // if the body of the template does not compile if the condition is not - // satisfied. - template <typename T, typename = std::enable_if<T::some_trait>> - void invalid_usage() { ... } - - // The tool suggests the following replacement for 'invalid_usage': - template <typename T, typename = typename std::enable_if<T::some_trait>::type> - void fixed_invalid_usage() { ... } - -C++14 introduced the trait helper ``std::enable_if_t`` which reduces the -likelihood of this error. C++20 introduces constraints, which generally -supersede the use of ``std::enable_if``. See -:doc:`modernize-type-traits <../modernize/type-traits>` for another tool -that will replace ``std::enable_if`` with -``std::enable_if_t``, and see -:doc:`modernize-use-constraints <../modernize/use-constraints>` for another -tool that replaces ``std::enable_if`` with C++20 constraints. Consider these -newer mechanisms where possible. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.md new file mode 100644 index 0000000000000..7608c7d7e870c --- /dev/null +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.md @@ -0,0 +1,34 @@ +```{title} clang-tidy - bugprone-incorrect-enable-shared-from-this +``` + +# bugprone-incorrect-enable-shared-from-this + +Detect classes or structs that do not publicly inherit from +`std::enable_shared_from_this`, because unintended behavior will +otherwise occur when calling `shared_from_this`. + +Consider the following code: + +````c++ +#include <memory> + +// private inheritance +class BadExample : std::enable_shared_from_this<BadExample> { + +// ``shared_from_this``` unintended behaviour +// `libstdc++` implementation returns uninitialized ``weak_ptr`` + public: + BadExample* foo() { return shared_from_this().get(); } + void bar() { return; } +}; + +void using_not_public() { + auto bad_example = std::make_shared<BadExample>(); + auto* b_ex = bad_example->foo(); + b_ex->bar(); +} +```` + +Using `libstdc++` implementation, `shared_from_this` will throw +`std::bad_weak_ptr`. When `using_not_public()` is called, this code will +crash without exception handling. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst deleted file mode 100644 index 968340a6e8f98..0000000000000 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-shared-from-this.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. title:: clang-tidy - bugprone-incorrect-enable-shared-from-this - -bugprone-incorrect-enable-shared-from-this -========================================== - -Detect classes or structs that do not publicly inherit from -``std::enable_shared_from_this``, because unintended behavior will -otherwise occur when calling ``shared_from_this``. - -Consider the following code: - -.. code-block:: c++ - - #include <memory> - - // private inheritance - class BadExample : std::enable_shared_from_this<BadExample> { - - // ``shared_from_this``` unintended behaviour - // `libstdc++` implementation returns uninitialized ``weak_ptr`` - public: - BadExample* foo() { return shared_from_this().get(); } - void bar() { return; } - }; - - void using_not_public() { - auto bad_example = std::make_shared<BadExample>(); - auto* b_ex = bad_example->foo(); - b_ex->bar(); - } - -Using `libstdc++` implementation, ``shared_from_this`` will throw -``std::bad_weak_ptr``. When ``using_not_public()`` is called, this code will -crash without exception handling. diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.md similarity index 69% rename from clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst rename to clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.md index bbbc8773868a4..14d861c3ca4fd 100644 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.rst +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/infinite-loop.md @@ -1,7 +1,7 @@ -.. title:: clang-tidy - bugprone-infinite-loop +```{title} clang-tidy - bugprone-infinite-loop +``` -bugprone-infinite-loop -====================== +# bugprone-infinite-loop Finds obvious infinite loops (loops where the condition variable is not changed at all). @@ -9,9 +9,9 @@ at all). Finding infinite loops is well-known to be impossible (halting problem). However, it is possible to detect some obvious infinite loops, for example, if the loop condition is not changed. This check detects such loops. A loop is -considered infinite if it does not have any loop exit statement (``break``, -``continue``, ``goto``, ``return``, ``throw`` or a call to a function called as -``[[noreturn]]``) and all of the following conditions hold for every variable +considered infinite if it does not have any loop exit statement (`break`, +`continue`, `goto`, `return`, `throw` or a call to a function called as +`[[noreturn]]`) and all of the following conditions hold for every variable in the condition: - It is a local variable. @@ -24,9 +24,9 @@ loop infinite since functions may return different values for different calls. For example, the following loop is considered infinite `i` is not changed in the body: -.. code-block:: c++ - - int i = 0, j = 0; - while (i < 10) { - ++j; - } +```c++ +int i = 0, j = 0; +while (i < 10) { + ++j; +} +``` diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.md new file mode 100644 index 0000000000000..35ff24b0225fc --- /dev/null +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.md @@ -0,0 +1,39 @@ +```{title} clang-tidy - bugprone-integer-division +``` + +# bugprone-integer-division + +Finds cases where integer division in a floating point context is likely to +cause unintended loss of precision. + +No reports are made if divisions are part of the following expressions: + +- operands of operators expecting integral or bool types, +- call expressions of integral or bool types, and +- explicit cast expressions to integral or bool types, + +as these are interpreted as signs of deliberateness from the programmer. + +Examples: + +```c++ +float floatFunc(float); +int intFunc(int); +double d; +int i = 42; + +// Warn, floating-point values expected. +d = 32 * 8 / (2 + i); +d = 8 * floatFunc(1 + 7 / 2); +d = i / (1 << 4); + +// OK, no integer division. +d = 32 * 8.0 / (2 + i); +d = 8 * floatFunc(1 + 7.0 / 2); +d = (double)i / (1 << 4); + +// OK, there are signs of deliberateness. +d = 1 << (i / 2); +d = 9 + intFunc(6 * i / 32); +d = (int)(i / 32) - 8; +``` diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst deleted file mode 100644 index 2c82e6fa18a3d..0000000000000 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/integer-division.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. title:: clang-tidy - bugprone-integer-division - -bugprone-integer-division -========================= - -Finds cases where integer division in a floating point context is likely to -cause unintended loss of precision. - -No reports are made if divisions are part of the following expressions: - -- operands of operators expecting integral or bool types, -- call expressions of integral or bool types, and -- explicit cast expressions to integral or bool types, - -as these are interpreted as signs of deliberateness from the programmer. - -Examples: - -.. code-block:: c++ - - float floatFunc(float); - int intFunc(int); - double d; - int i = 42; - - // Warn, floating-point values expected. - d = 32 * 8 / (2 + i); - d = 8 * floatFunc(1 + 7 / 2); - d = i / (1 << 4); - - // OK, no integer division. - d = 32 * 8.0 / (2 + i); - d = 8 * floatFunc(1 + 7.0 / 2); - d = (double)i / (1 << 4); - - // OK, there are signs of deliberateness. - d = 1 << (i / 2); - d = 9 + intFunc(6 * i / 32); - d = (int)(i / 32) - 8; diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.md b/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.md new file mode 100644 index 0000000000000..7ab9e51bbdc91 --- /dev/null +++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.md @@ -0,0 +1,82 @@ +```{title} clang-tidy - bugprone-invalid-enum-default-initialization +``` + +# bugprone-invalid-enum-default-initialization + +Detects default initialization (to 0) of variables with `enum` type where +the enum has no enumerator with value of 0. + +In C++ a default initialization is performed if a variable is initialized with +initializer list or in other implicit ways, and no value is specified at the +initialization. In such cases the value 0 is used for the initialization. +This also applies to enumerations even if it does not have an enumerator with +value 0. In this way a variable with the `enum` type may contain initially an +invalid value (if the program expects that it contains only the listed +enumerator values). + +The check emits a warning only if an `enum` variable is default-initialized +(contrary to not initialized) and the `enum` does not have an enumerator with +value of 0. The type can be a scoped or non-scoped `enum`. Unions are not +handled by the check (if it contains a member of enumeration type). + +Note that the `enum` `std::errc` is always ignored because it is expected +to be default initialized, despite not defining an enumerator with the value 0. + +```c++ +enum class Enum1: int { + A = 1, + B +}; + +enum class Enum0: int { + A = 0, + B +}; + +void f() { + Enum1 X1{}; // warn: 'X1' is initialized to 0 + Enum1 X2 = Enum1(); // warn: 'X2' is initialized to 0 + Enum1 X3; // no warning: 'X3' is not initialized + Enum0 X4{}; // no warning: type has an enumerator with value of 0 +} + +struct S1 { + Enum1 A; + S(): A() {} // warn: 'A' is initialized to 0 +}; + +struct S2 { + int A; + Enum1 B; +}; + +S2 VarS2{}; // warn: member 'B' is initialized to 0 +``` + +The check applies to initialization of arrays or structures with initialization +lists in C code too. In these cases elements not specified in the list (and have +enum type) are set to 0. + +```c +enum Enum1 { + Enum1_A = 1, + Enum1_B +}; +struct Struct1 { + int a; + enum Enum1 b; +}; + +enum Enum1 Array1[2] = {Enum1_A}; // warn: omitted elements are initialized to 0 +enum Enum1 Array2[2][2] = {{Enum1_A}, {Enum1_A}}; // warn: last element of both nested arrays is initialized to 0 +enum Enum1 Array3[2][2] = {{Enum1_A, Enum1_A}}; // warn: elements of second array are initialized to 0 + +struct Struct1 S1 = {1}; // warn: element 'b' is initialized to 0 +``` + +## Options + +```{option} IgnoredEnums +Semicolon-separated list of regexes specifying enums for which this check won't be +enforced. Default is `::std::errc`. +``` diff --git a/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst b/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst deleted file mode 100644 index fcbfce751828d..0000000000000 --- a/clang-tools-extra/docs/clang-tidy/checks/bugprone/invalid-enum-default-initialization.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. title:: clang-tidy - bugprone-invalid-enum-default-initialization - -bugprone-invalid-enum-default-initialization -============================================ - -Detects default initialization (to 0) of variables with ``enum`` type where -the enum has no enumerator with value of 0. - -In C++ a default initialization is perfor... [truncated] `````````` </details> https://github.com/llvm/llvm-project/pull/214418 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
