You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[include-cleaner] don't consider the associated header unused (llvm#67228)
Loosely, the "associated header" of `foo.cpp` is `foo.h`.
It should be included, many styles include it first.
So far we haven't special cased it in any way, and require this include
to be justified. e.g. if foo.cpp defines a function declared in foo.h,
then the #include is allowed to check these declarations match.
However this doesn't really align with what users want:
- people reasonably want to include the associated header for the
side-effect of validating that it compiles.
In the degenerate case, `lib.cpp`is just `#include "lib.h"` (see bug)
- That `void foo(){}` IWYU-uses `void foo();` is a bit artificial, and
most users won't internalize this. Instead they'll stick with the
simpler model "include the header that defines your API".
In the rare cases where these give different answers[1], our current
behavior is a puzzling special case from the user POV.
It is more user-friendly to accept both models.
- even where this diagnostic is a true positive (defs don't match header
decls) the diagnostic does not communicate this usefully.
Fixesllvm#67140
[1] Example of an associated header that's not IWYU-used:
```
// http.h
inline URL buildHttpURL(string host, int port, string path) {
return "http://" + host + ":" + port + "/" + path;
}
// http.cpp
class HTTPURLHandler : URLHandler { ... };
REGISTER_URL_HANDLER("http", HTTPURLHandler);
```
0 commit comments