[PATCH] D125769: [clang-tidy] Introduce the WarnIntoHeaders option to modernize-deprecated-headers

[Whisperity via Phabricator via cfe-commits]

whisperity added inline comments.


================
Comment at: clang-tools-extra/clang-tidy/modernize/DeprecatedHeadersCheck.h:63
   std::vector<detail::IncludeMarker> IncludesToBeProcessed;
+  bool WarnIntoHeaders;
 };
----------------
LegalizeAdulthood wrote:
> 1) How is this different from the clang-tidy option that specifies whether or not fixits are applied to header files?
> 
>   As an owner of a code base, I would know which header files are included from C source files and I would set my header-file regex (honestly, not a fan of a regex for that option; I'd prefer white/black lists, but that's another discussion) to exclude header files that are known to be included in C source files.
> 
> 2) Assuming that the header-file regex is somehow insufficient to cover this scenario, I like the functionality but the name of this option feels "off".  (Naming things is hard.)  Elsewhere we have options that say `HeaderFile` not `Headers` and `Into` just doesn't sound like the way normal conversation would state the situation.  Something like `CheckHeaderFile` would be more consistent with existing options.
I do not know the answer to question //1//, but as an owner of a code-base, I would not want to know or deal with keeping additional lists (be it file-by-file, glob expressions, or regex...) specific to what headers are includable from C and what aren't. Especially considering that every C header could be included from C++. (Note how LLVM uses `.h` instead of `.hpp` for its headers, even though >90% of our headers would never compile in C mode...) If a check is misbehaving for my codebase, I'd just simply disable that check (1 line of code) and go on with my life, instead of creating a curated list, that is //at least// 2 LoC in a config file, //and// has to be maintained down the line...

Moreover, the `-header-filter` regex and `-system-headers` are Tidy-level global flags. This means that I would either have to let go of EVERY potential diagnostic that might be placed in headers, or tinker with my environment to run multiple instances of Clang-Tidy with different configurations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125769/new/

https://reviews.llvm.org/D125769