| Issue |
208187
|
| Summary |
[clang-tidy] Conflicts between cppcoreguidelines-init-variables and clang-analyzer-deadcode.DeadStores
|
| Labels |
clang-tidy
|
| Assignees |
|
| Reporter |
fekir
|
It is difficult to make both `cppcoreguidelines-init-variables` and `clang-analyzer-deadcode.DeadStores` happy, at least without adding additional redirections.
Just as an example
~~~~
enum class e {e1=1,e2,e3};
void foo(int i){
e value;
switch(i){
case 1: value=e::e1;
case 2: value=e::e2;
case 3: value=e::e3;
default: return; // or default: value=e1;
}
// use value from here on
}
~~~~
Since `e value;` does not initialize the value, `cppcoreguidelines-init-variables` emits a diagnostic.
But if the code is changed to `e value = {};`, then `clang-analyzer-deadcode.DeadStores` complains, because `value` is always overwritten.
If the switch looks like
~~~~
switch(i){
case 1: value=e::e1;
case 2: value=e::e2;
case 3: value=e::e3;
default: value=e::e1;
}
~~~~
then the code can be rewritten as
~~~~
auto value = [&]{switch(i){
case 1: return e::e1;
case 2: return e::e2;
case 3: return e::e3;
default: return e::e1;
}}();
~~~~
but with the `return` statement, more boilerplate is necessary, which makes the code harder to follow.
I think there is an advantage of having the following pattern accepted by `cppcoreguidelines-init-variables` (with an option eventually), instead of locally silencing the warning
~~~~
e value;
switch(i){
case 1: value = e::e1;
case 2: value = e::e2;
case 3: value = e::e3;
default: return;
}
// use value from here on
~~~~
If a new `case` is added, which does not initialize `value`, then `cppcoreguidelines-init-variables` would diagnose it.
If the warning was silenced locally, then there would be no warning for the new `case` statement.
Changing the code to
~~~~
e value = {};
switch(i){
case 1: value = e::e1;
case 2: value = e::e2;
case 3: value = e::e3;
default: return;
}
// use value from here on
~~~~
has the disadvantage that adding a new `case` that does not initialize `value` properly will not be diagnosed.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
