[clang-tidy] misc-include-cleaner incompatible with modernize-deprecated-headers ?

[Zitrax]

I have not found any way to fix code like this without suppressing with NOLINT or similar.

#include <iostream>

// Including this triggers:
//   inclusion of deprecated C++ header 'string.h'; consider using 'cstring' instead [modernize-deprecated-headers]
#include <string.h>

// Including this instead triggers:
//   no header providing "strsignal" is directly included [misc-include-cleaner]
#include <cstring>

int main() {
    std::cout << strsignal(2) << "\n";
    return 0;
}

The warning from modernize-deprecated-headers makes sense but shouldn't misc-include-headers allow using the modern C++ headers like cstring here without warning?

Godbolt example: https://godbolt.org/z/5TxEvK3P6

Tested with clang-tidy 17.0.6 and 18.0.0

[llvmbot]

@llvm/issue-subscribers-clang-include-cleaner

Author: Daniel Bengtsson (Zitrax)

I have not found any way to fix code like this without suppressing with `NOLINT` or similar.

#include <iostream>

// Including this triggers:
//   inclusion of deprecated C++ header 'string.h'; consider using 'cstring' instead [modernize-deprecated-headers]
#include <string.h>

// Including this instead triggers:
//   no header providing "strsignal" is directly included [misc-include-cleaner]
#include <cstring>

int main() {
    std::cout << strsignal(2) << "\n";
    return 0;
}

The warning from modernize-deprecated-headers makes sense but shouldn't misc-include-headers allow using the modern C++ headers like cstring here without warning?

Godbolt example: https://godbolt.org/z/5TxEvK3P6

Tested with clang-tidy 17.0.6 and 18.0.0

[pkasting]

strsignal() is POSIX, not standard C, right?
Is guaranteed to provide all the symbols of the platform's string.h, even ones not in the C spec?
If it is, I don't think it's guaranteed to export them out of namespace std?

All this is my way of saying, I think in this case you want <string.h> // NOLINT, and the misc-include-headers warning is correct.

[Zitrax]

I think you are right about that.

Still it would be nice if these two checks could co-exist without littering the code with suppressions. cstring includes string.h directly without any protection.