I’ve asked this question in StackOverflow without much success so I thought I’d come closer to the source and ask here.
My use case is simple: ignore compiler warnings from 3rd-party headers that I have no control over. The standard approach for this is simple - include them as “system headers” via “-isystem”. That works pretty well, except for one bit - macros. Clang (and GCC) will still report warnings if I use problematic macros each time I use them in my code. Why is that? Clang knows where the macro comes from, shouldn’t it be able to ignore the warning? Is there a good way to achieve what I want, without using pragmas or re-creating the third-party code myself?
+Some folks who have some interest in clang diagnostic quality.
I’m guessing there isn’t an existing solution to this in clang - but maybe it’s possible if you wanted to work on an improvement/patch to Clang? Though it might be difficult to check that all the relevant code properties came from the macro and not some from the macro, some from macro arguments, some from the context the macro was used in, etc.
Thanks for the response! I went ahead and put up a patch to introduce support for disabling warnings from macros on a per-warning level. It’s implemented following the great feedback I received and works for my concrete use case (disable a particular warning). After it’s merged people should be able to suppress other warnings if they see fit. However, as I said in the comments, I believe this behavior should be consistent with “ShowInSystemHeader”, i.e. explicitly opt-in to get warnings from macros instead of opt-out. But that’s not up to me to decide, I’m keeping current behavior (all warnings on by default)