[cfe-dev] How to suppress a specific diagnostic?

Arthur O'Dwyer arthur at push.am
Thu Apr 26 17:38:30 PDT 2012


Okay, I feel like this ought to be a REALLY simple question, but I can't
figure it out. If clang is giving me a spammy warning, how do I turn off
that warning?

I've got some autogenerated code (like, megabytes of it). This code
contains some dubious practices, call them A and B; but I'm stipulating
that practices A and B are actually perfectly fine in this specific
instance. I need to tell clang to shut up about A and B; but at the same
time, if other dubious practices such as C or D start showing up unbidden,
I'd kind of like clang to catch those; i.e., I know I could just pass "-w",
but that's a little blunt for this case.

I'm coming from the world of EDG, where each diagnostic's severity level
can be toggled independently (except for those diagnostics that indicate an
uncompilable program). If I want to turn off warning #42, I just say
--diag_suppress=42, and it's suppressed. But I can't figure out how to find
out the unique identifiers associated with clang's warnings.

To take a concrete example, let's say I have the following Objective-C
code. I want to suppress the two bogus warnings about the @property (its
getter and setter aren't going to be @synthesized anyway), but I still want
to see the warning about division by zero. Or, alternatively, maybe I want
to suppress the division-by-zero warning (maybe it's in unreachable code)
but I still want to see the other warnings.
  @interface Foo
  @property Foo *foo;
  @end
  void f(int x) { x /= 0; }

Is this just impossible with the current implementation of error handling
in clang? If not, awesome! how do I do it?  Or, if so, are there any plans
on the development roadmap to improve error handling to the point where
users *can* toggle each diagnostic independently?

Thanks,
-Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120426/53d8ccb3/attachment.html>


More information about the cfe-dev mailing list