How to suppress a specific diagnostic?

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

There are a couple ways to do this. If the warnings have individual flags (-Wfoo), you can disable them individually (-Wno-foo). This is probably what you want, and what existing users of Clang and GCC are familiar with.

If the warning you're interested in does /not/ have an individual flag (and most warnings mention which flag they're associated with in their diagnostic message), you could even file a bug, since we're working towards getting every warning under a flag. It's possible the warning /does/ have a flag, but doesn't say in the diagnostics, in which case you could see if it's in GCC's list of warnings. (Anything we both warn about, we try to make compatible with GCC, and sadly their warnings have better documentation.)

Even then, though, it might be better to use GCC's diagnostic pragmas to only disable the warnings around dubious practices A and B. Clang supports these pragmas; check out http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html for their usage.

Is that what you were looking for?
Jordy

Well, most warnings tell you exactly how to disable them. It's a bug if
a warning does not have a corresponding option to disable it. So what
warning are you talking about?

Joerg

If the warning you're interested in does /not/ have an individual flag
(and most warnings mention which flag they're associated with in their
diagnostic message),

You guessed it. The warnings that do mention flags aren't *so* much of
a problem, although it's still annoying that I can't turn off just one
specific warning --- e.g. if the spammy warning is about unused
parameters, I have to pass e.g. -Wno-unused to turn off *all* warnings
that relate to unused things, not just parameters.

you could even file a bug, since we're working towards
getting every warning under a flag.

Surely the Right Answer really is to copy EDG's way of doing it, and
assign each diagnostic a unique identifier (which is to say, a unique
integer) --- which will also help with internationalization, if anyone
ever wants to translate all the error messages to a different language
and needs to unambiguously refer to a message for that reason.

-Arthur

Then clang is full of bugs that I assume must be trivial to grep for. :wink:

When I feed my example autogenerated code to clang 3.1
(tags/Apple/clang-318.0.58), I get this output:

x.m:2:1: warning: no 'assign', 'retain', or 'copy' attribute is
specified - 'assign' is assumed
@property Foo *foo;
^
x.m:2:1: warning: default property attribute 'assign' not appropriate
for non-gc object
x.m:4:18: warning: division by zero is undefined
void f(int x) { x/=0; }
                 ^ ~

That's three distinct warnings with no options to toggle any of them.
Unless ToT has addressed these warnings already.

-Arthur

It's a bug if a warning does not have a corresponding
option to disable it. So what warning are you talking about?

Then clang is full of bugs that I assume must be trivial to grep for. :wink:

Even easier than greping - we have a list of unnamed warnings & a tool
that checks that we don't ever increase/add things to this list (& if
we ever remove things from it, they stay removed). It's just not an
immediate priority for someone to spend the time to group & name all
these warnings appropriately.

Patches welcome? :slight_smile: preferably if they're named the same as GCC's
diagnostics, if any match already. (or, if GCC's name is particularly
bad or at odds with Clang's naming conventions, an alias for GCC's
name & another name that matches Clang's can be provided)

- David

Objective-c is the oldest dialect of c added to clang. As such, old warnings have not
kept up with new rules regarding having a diagnostic flag to turn them off/on.

- Fariborz

Hi Arthur,

Please file a Bugzilla PR, so we can track fixing this. The reality is that not all of the warnings are guarded under flags, but the goal is to eventually have all of them covered under flags.

Thanks,
Ted