On Wed, Jul 10, 2013 at 1:20 PM, Gabriel Dos Reis <g...@integrable-solutions.net> wrote: > On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li <davi...@google.com> wrote: >> There are two fundamental problems: >> 1) uninit warning has false positives. >> 2) people disagree what is the expected behavior of -Wall. >> >> 1) can only be solved by improving the analysis. > > I think we should focus on this. While we can't attain perfection > here, there is room for improvement for the cases that > actually matter. > >> The new option is a >> reasonable way to solve 2), unless you think the only way to solve it >> is to change the behavior of -Wall, or ask concerned user to >> explicitly use -Wno-error=... or white list the warning options they >> care. > > I do consider that -Wall should be 'reasonably' free of annoying false > positives, and that should be fixed by improving the detection > analysis, of by removing the switch from -Wall. This is the > recipe we've applied so far, and it usually works. Of course, > a workaround, while waiting for the improvement, is to list > the diagnostics that are at fault in -Wno-error=. > > In general, I think we are too eager to add new switches, but > we have no framework in place to test the coherence of the > various switches we keep adding. A key attractive aspect > of -Wall is that one does not need to know the gazillion > switches that are activated. One can make a case that everyone > should know all of them, but that I think it is misguided to > require every user to know everything we put in -Wall. >
This points to other ideas: 1) how about adding a helper switch to show what is included in Wall? such as -Wall-print 2) how about making -Wall configurable -- a default config file is looked at by the compiler, but user can change the config or use a different config they like. David > -- Gaby