[cfe-dev] Pragma warning control

[Dan Villiom Podlaski Christiansen]

On 10 Jan 2009, at 13:05, Sebastian Redl wrote:

> That's just a question of the definition of default's behavior. :-) Is
> it defined to
> - Enable the warning (but then it should be called 'enable')
> - Enable the warning if it would be enabled without any pragma (then  
> it
> has to respect all command line options)
> - Enable the warning if it would be enabled without any pragma or
> command line option specific to this warning (then it has to respect
> general options like -pedantic or -w).
>
> The name 'default' in the MS compiler comes from their warning scheme.
> The MS compiler has warning levels 0-4. Every warning has an  
> associated
> level and is enabled if the level is that or higher, so level 0 is no
> warnings, and level 4 is all warnings. 'Default' then means to reset  
> the
> warning to the behavior it has at the specified warning level.
> But Clang doesn't have warning levels, so we have to redefine or  
> rename
> default.

How about a stack-based approach? That is, a change is pushed on to  
the warning stack. A change is then reverted by popping it from the  
stack; either by naming it explicitly or an indiscriminate ‘pop’.

For example:

>> // warn about these
>> #pragma Clang warning(push: format-nonliteral)
>> … some code …
>> // revert this warning to its pre-specified behaviour
>> #pragma Clang warning(pop: format-nonliteral)
>>
>> // don't warn about these
>> #pragma Clang warning(push: no-dead-store)
>> … some code …
>> // revert the most recent change
>> #pragma Clang warning(pop)

(An alternate syntax: ‘#pragma Clang push(warnings, no-dead- 
store)’, and so on.)

Maybe strict ordering of pushes and pops should be required; I'm  
mostly thinking of this as a user, so I have no opinion about that :)

With regards to warning names, I'd suggest changing them to match  
command-line options. This involves removing the ‘warn’ prefix —  
which seems redundant to me — and changing underscores to dashes.  
Combined with a change to make diagnostic names more closely match GCC  
warning flags, and introducing ‘meta-diagnostics’ (if you can say  
that) to match things like -Wall, -Wextra, -Wformat, -Wsecurity and so  
on, affecting the default values of individual diagnostics. Prefixing  
a diagnostic name with ‘no-’ would have the effect of turning it  
off.

This might be useful for simplifying the driver, which would contain  
little or no information about the actual diagnostics. In the future,  
it might even be useful for retaining warning flags by embedding them  
into a serialised AST.

Having tried to compile a few programs with Clang, I noticed that  
warning options don't match GCC. It seems to me that naming core  
diagnostics compatibly would be preferable to having to translate them.

--

Dan Villiom Podlaski Christiansen, stud. scient.,
danchr at cs.au.dk, danchr at gmail.com