[cfe-dev] proposal: every warning should have a -W flag

Douglas Gregor dgregor at apple.com
Tue Aug 9 15:49:48 PDT 2011


On Aug 9, 2011, at 3:31 PM, David Blaikie wrote:

>> We can have our cake and eat it too, perhaps.  Group the warnings
>> logically, but allocate blocks of warning numbers with padding for
>> future expansion.  For instance, numeric warnings are all in the D1000
>> - D1100 range.  Then we can still split warnings into more specific
>> diagnostics, allocate them new numbers, but are able to keep the
>> grouping cohesive.
> 
> To be honest I wasn't really pushing the numbering aspect of VC's
> diagnostic handling so much as I was the unique-ness.
> 
>> This, of course, is predicated on the thought that having individual
>> warning numbers is useful to the majority of people.  From personal
>> experience, I like having a warning number because it makes it easier
>> to Google for others who've had the same issue.  Most diagnostics
>> contain source-specific information, and so Google searches become a
>> guessing game of what keywords are important.  YMMV
> 
> But yes, this is the selling point for having numbered diagnostics.

This is the selling point of having a unique searchable name. It doesn't have to be an otherwise-meaningless number.

> I
> do actually prefer the named diagnostics that clang uses in both
> compiler output and pragma suppressions - they're more
> self-documenting (when I look through a make file & see suppressions
> for 3 different VC warnings as just numbers - they either have to have
> comments or I have to google up the docs to see what they do. With
> clang I don't get random numbers in my compiler messages, instead I
> get a nice string telling me the name of the warning so I can suppress
> it if I want (or turn it on if I'm not seeing that in another build)).
> 
> & the names clang uses should be fairly searchable (obviously as clang
> usage increases & these sort of questions turn up in documentation,
> forums, etc, more)


Yeah, agreed on all points.

	- Doug



More information about the cfe-dev mailing list