[cfe-dev] Pragma warning control

Sebastian Redl sebastian.redl at getdesigned.at
Fri Jan 9 14:52:45 PST 2009


Hi,

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


Is there interest in such a feature? I know that GCC's inability to
control most warnings within a source file causes problems in the Boost
project from time to time.


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

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

Sebastian



More information about the cfe-dev mailing list