[cfe-dev] Pragma warning control

[Sebastian Redl]

Douglas Gregor wrote:
> Hi Sebastian,
>
> On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote:
>>
>> 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.
>

What do you mean? In the code? A pragma can appear anywhere. (Although -
what *is* the effect of a pragma in the middle of an expression?)

>> - 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.
>

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.

>> - 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.
>

Yes. Another boring housekeeping job.

>> 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.

That's a possibility, but it really requires a consistent naming scheme,
and one that is exposed to the user, so it has to make sense for both
developers and users.
So I think I'll go with building the map for now.

Sebastian