| Issue |
143979
|
| Summary |
[clang-tidy] Check request: bugprone-overloads-in-different-headers
|
| Labels |
clang-tidy
|
| Assignees |
|
| Reporter |
denzor200
|
Need a check that will find overloads of the same function declared in different headers.
The usefulness of this check is to find the case when the behavior of the program depends on order of `#include` which can be changed during refactoring, and no one expects behavior to change with such refactoring.
The check will work with only built in types, to catch same probled for `struct`, `class` and `enum` we need more complicated strategy due to ADL.
The check will not provide a fixit hint because a solution to fix might be too complicated.
math_utils.h
```
#include <iostream>
inline void compute(int value) { // BAD - found another one in advanced_math.h
std::cout << "int" << std::endl;
}
```
advanced_math.h
```
#include <iostream>
inline void compute(float value) { // BAD - found another one in math_utils.h
std::cout << "float" << std::endl;
}
```
The check will give one false positive in the case where the overloads never conflict:
utils.h
```
inline void process(int value) { // BAD - this is FP
}
```
advanced_utils.h
```
inline void process(char* value) { // BAD - this is FP
}
```
Filtering such cases would require us to emulate SFINAE on the Clang Tidy side, in my opinion the effort would not be worth the result, since such situations are very rare.
Let's show how the headers reordering can affect the behavior of the program.
Assume we have a third header file `business_logic.h`:
```
#include "math_utils.h"
template<typename T> void process(T x) {
compute(x);
}
```
And then we can use those three headers in the example:
```
#include "math_utils.h"
#include "advanced_math.h"
#include "business_logic.h"
int main() {
process(1.0f); // Puts "float"
}
```
As we can see, this works correctly, as expected by most of us.
Let's change the order of two header and see what happens:
```
#include "math_utils.h"
#include "business_logic.h"
#include "advanced_math.h"
int main() {
process(1.0f); // Puts "int"
}
```
The output result was changes because here we reproduced another problem described in [bugprone-unreached-function-overload](https://github.com/llvm/llvm-project/issues/143329).
The check should show a warning message for both samples above, unlike bugprone-unreached-function-overload which shows problems that have already occurred, this check will show a potential problem.
The idea for this check was co-authored with @vbvictor, inspired by the [article](https://akrzemi1.wordpress.com/2015/11/19/overload-resolution/) by @akrzemi1.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
