#830 Cannot disable all warnings but one

closed-fixed
None
5
2007-12-12
2007-05-29
Luke Moore
No

It's not possible to disable all warnings but one (or n, in the general case). Suppose one wants to enable all warnings except 509. When -Wall is turned on, all other warning filters are ignored, so -Wall -w509 cannot be used.

So, the next approach one might try would be to use -w509,+202,+309,+403,+512,+321,+322, to disable 509 and enable the warnings that swig disables by default. However, because Swig_warnfilter() prepends to the warning filter list, the warn filter starts as

-202,-309,-403,-512,-321,-322

then gets set to

-509,+202,+309,+403,+512,+321,+322,-202,-309,-403,-512,-321,-322

Now, warning 509 does indeed get ignored. However, 202, for example, is still ignored. The reason it is ignored is that Swig_warning scans through the warning filter for all the ones matching the warning number, and uses the *last* match found. So, it uses the -202 filter because it comes after the +202 filter.

One fix would be to break out of the loop in Swig_warning() when the first match is found.

It would be great if there was an option like -Wall that only cleared the default warn filter, instead of disabling all warning filters.

Discussion

  • Olly Betts
    Olly Betts
    2007-05-31

    Logged In: YES
    user_id=14972
    Originator: NO

    I think you mean "It's not possible to ENABLE all warnings but one".

    -Wall is documented to disable all other warning filters, but that makes it behave differently to GCC's -Wall ("gcc -Wall -Wno-foo" does what you'd expect) so personally I'm not sold on that being the right thing to do.

    So I think that the two things -Wall does now should be separated and that -Wall should simply turn on the extra warnings, and there should be a new option (say -Wnofilters) to disable all other warning filters. The manual doesn't say why this is useful, but I guess it's so you can take a look at all the warnings being suppressed when trying to debug a SWIG interface file.

    It also sounds like Swig_warning() should break out of the loop at the first match as you suggest (which would be more efficient too!)

    But this might be controversial. If you're interested in working on a patch, I'd suggest asking on the swig-dev mailing list (actually, tracker updates are sent to the dev list, but of course people may not actually read them...)

     
  • William Fulton
    William Fulton
    2007-12-12

    Logged In: YES
    user_id=242951
    Originator: NO

    This is similiar to #1754967 which has been resolved for swig-1.3.32. Please see the updated Warnings.html documentation and the CHANGES entry dated 08/31/2007.

     
  • William Fulton
    William Fulton
    2007-12-12

    • assigned_to: nobody --> wsfulton
    • status: open --> closed-fixed