[cfe-dev] Pragma warning control

[Douglas Gregor]

Hi Sebastian,

On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote:
> I'm thinking of implementing a pragma to control Clang warnings. This
> would look something like this (borrowing MS syntax because it makes
> sense, IMO):
>
> struct A;
>
> void f(A *a) {
> #pragma Clang warning(disable: warn_delete_incomplete)
>  // This would cause the warning, but I know it to be safe:
>  delete a;
>  // Bring warning back to its default status so that real issues  
> aren't
> missed.
> #pragma Clang warning(default: warn_delete_incomplete)
> }
>
> Alternatively, this could be done with an attribute, but I actually
> think that a pragma is the better choice here. (Among other things,
> because it can then control preprocessor, lexer and parser warnings.)

I, too, prefer the pragma. Microsoft did a good job with this one.  
#pragma warning(push) and #pragma warning(pop) are particularly good  
for headers (where disabling warnings seems to matter the most to  
users).

>
> Is there interest in such a feature?

Yes!

> I know that GCC's inability to
> control most warnings within a source file causes problems in the  
> Boost
> project from time to time.

Yes, it definitely annoys users when they can't turn off a bogus or  
unwanted warning.

>
> Some concrete issues I can think of:
> - Template instantiation would ideally save the warning status around
> the definition of a template and reintroduce it during instantiation;
> else you for example disable truncation warnings around the template
> definition, but instantiations cause the warning anyway.

Yep. This probably means that these pragmas will need to be able to  
appear wherever (at least) declarations can appear.

> - Explicitly disabling warnings at the command line could either share
> status storage with this feature, but then warning(default: id) would
> enable warnings that were disabled at the command line. Alternatively,
> the feature could have its own storage, but that means doubling the
> required memory.

I think warning(default: id) should not change its behavior based on  
the options on the command line.

> - We would really need to make diagnostic continuations somehow a part
> of the original diagnostic, or we could get dangling notes. (Or do we
> get them already with -w? Do we have any warnings that have dependent
> notes?)

There are other good reasons for doing this, too, such as providing  
non-terminal clients with enough information to group all of the notes  
as part of a single warning/error message.

> - We should probably clean up the names of the diagnostics. In the  
> long
> run, this means that the names of the diagnostics become part of the
> public interface of the compiler, which means we can't change them at
> will anymore.

Yeah, and we'll want to try to weed out any duplicates, too (yuck).  
Still, this is work that we'll just have to do.

> To implement this, I would create a lazily initialized map from  
> names to
> the actual integers. Better, from many viewpoints, would be a sorted
> array of the names, searched by binary search (no initialization
> necessary, it's all read-only data), but that's not possible due to  
> the
> lack of string processing abilities in the preprocessor and template
> meta-engines. (In non-pompous terms, I can't sort strings at compile- 
> time.)

We could require that the entries in DiagnosticKinds be sorted, with a  
Debug-only sortedness check at start-up. Actually, that would help  
force us to come up with more consistent diagnostic names, since  
getting related diagnostics together means giving them similar names.

I think this would make a great addition to Clang.

	- Doug