<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-12-23 18:05 GMT+01:00 Piotr Padlewski <span dir="ltr"><<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">2016-12-23 17:57 GMT+01:00 Malcolm Parsons <span dir="ltr"><<a href="mailto:malcolm.parsons@gmail.com" target="_blank">malcolm.parsons@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div>On 13 Dec 2016 12:45 p.m., "Piotr Padlewski" <<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-4038023257146576752m_-5890296460672414216m_1786174154975103070quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I don't mind having google/llvm specific checks in list (as links).</div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I like the way clang-format handles this; the --style option allows different organisations to have different default settings.</div><div dir="auto"><br></div><div dir="auto">How about removing the aliases and having --defaults={llvm,google,cert,c<wbr>ppcoreguidelines} select a default set of checks and options.</div><span class="gmail-m_-4038023257146576752HOEnZb"><font color="#888888"><div dir="auto"><br></div></font></span></div></blockquote></span><div>I really like this idea</div><span class="gmail-HOEnZb"><font color="#888888"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="gmail-m_-4038023257146576752HOEnZb"><font color="#888888"><div dir="auto"></div><div dir="auto"></div><div class="gmail_extra" dir="auto"><span style="font-family:sans-serif">-- </span><br style="font-family:sans-serif"><span style="font-family:sans-serif">Malcolm Parsons</span><br></div></font></span></div>
</blockquote></font></span></div><br></div></div>
</blockquote></div>Thinking more about it I think that we should come up with some new level o categorization of check if we would like to make this tool very easy to use.</div><div class="gmail_extra">I would like to have some kind of flag that would use some default checks, that we know are useful for < 95% of users, have very little false positives.</div><div class="gmail_extra">Each level (let say 4 levels like with optimizations) would have different set of checks, where -W0 would be as good as -Wall in frontend (it would be extended to checks that are useful but can't be in clang because analysis would take too long). One check could be enabled in multiple levels with different options, f.e.</div><div class="gmail_extra">modernize-loop-convert in -W0 would use MinConfidence: safe, and in -W1: resonable and in -W3: risky.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I know that now we would have to get to consensus about which checks are usefull on which level, but because the levels would be something that user should not relay on, we could change the configuration every time someone fix a bug or report a bug. And the same thing is in frontend (if warning should go to -Wall or not) and people get to consensus what diagnostic is good enough to be in which group.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Piotr</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>