Right now I get errors like this:
../../archer/gdb/python/python.c:415:25: error: Mismatching type in call to PyArg_ParseTuple with format code "L" [-fpermissive]
Note the [-fpermissive]. This is shown by -fdiagnostics-show-option, which lets users know how to disable a message.
The particular option here comes because the plugin calls permerror instead of one of the more generic functions, like error or warning.
Is this intentional?
It seems to me that it would be better to expose all the gcc machinery here. It isn't ideal (I'm not sure if a plugin can add a new -W option), but better I think than putting all errors into one bucket.
Tom
Tom> It seems to me that it would be better to expose all the gcc machinery Tom> here. It isn't ideal (I'm not sure if a plugin can add a new -W Tom> option), but better I think than putting all errors into one bucket.
It occurs to me that for the particular case of the PyArg_ParseTuple checker, -Wformat would be appropriate.
Tom
On Fri, 2011-06-24 at 12:36 -0600, Tom Tromey wrote:
Right now I get errors like this:
../../archer/gdb/python/python.c:415:25: error: Mismatching type in call to PyArg_ParseTuple with format code "L" [-fpermissive]
Note the [-fpermissive]. This is shown by -fdiagnostics-show-option, which lets users know how to disable a message.
The particular option here comes because the plugin calls permerror instead of one of the more generic functions, like error or warning.
Is this intentional?
It seems to me that it would be better to expose all the gcc machinery here. It isn't ideal (I'm not sure if a plugin can add a new -W option), but better I think than putting all errors into one bucket.
I agree that permerror is the wrong function here. I think I must have misread the comment in gcc/diagnostic.c
gcc's warning mechanism is keyed off of options: internally you pass in an enum opt_code, which (in theory) can control whether or not the warning is printed.
I wrapped up enum opt_code as a new gcc.Option type in this commit: http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commit;h=acf67963...
I then added gcc.error() and gcc.warning() methods in this commit: http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=46a6...
This means that you can now write python code like this:
gcc.warning(func.start, gcc.Option('-Wformat'), 'Incorrect formatting')
and thus emit a warning, controlled by the -Wformat/-Wno-format options.
That's the theory, anyway :(
I started porting libcpychecker to use this approach,with gcc.Option('-Wformat'), but ran into a problem: it turns out that GCC's warning-reporting within diagnostic_report_diagnostic() uses:
if (!option_enabled(...)) return false
to suppress disabled warnings.
Unfortunately, for many options (including -Wformat), option_enabled() returns -1 to signify that an option "isn't a simple on-off switch"; a naive call to: warning(loc, OPT_Wformat, "%s", msg) thus gets reported even if "-Wno-format" is set, since -1 is treated as truth.
As it turns out, there is a global boolean underlying this specific option, and in GCC's own usage of this, all of the warnings are guarded by this underlying boolean.
So I've implemented a nasty workaround for this as: http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=19f0... which tells the plugin which global variable to actually look at. It seems that this has to be fixed on an option-by-option basis, alas.
There doesn't seem to be a way of adding new command-line options from a plugin, so it may be that the better way for a plugin to emit its own warning and support fine-grained enable/disable of that warning is to mimic GCC's warning mechanism from Python.
Dave
gcc-python-plugin@lists.stg.fedorahosted.org