<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 2, 2018 at 11:05 AM, Roman Lebedev via Phabricator via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">lebedev.ri added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D44883#1054326" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D44883#1054326</a>, @thakis wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D44883#1048751" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D44883#1048751</a>, @dblaikie wrote:<br>
><br>
> > Historically Clang's policy on warnings was, I think, much more<br>
> >  conservative than it seems to be today. There was a strong desire not to<br>
> >  implement off-by-default warnings, and to have warnings with an<br>
> >  exceptionally low false-positive rate - maybe the user-defined operator<br>
> >  detection was either assumed to, or demonstrated to, have a sufficiently<br>
> >  high false positive rate to not meet that high bar.<br>
><br>
><br>
> This is still the case. For a new warning, you should evaluate some large open-source codebase and measure true positive and false positive rate and post the numbers here.<br>
<br>
<br>
</span>I did run it on stage-2 of LLVM itself. The only 'false-positives' so far are already present in trunk:<br>
<a href="https://godbolt.org/g/SXc4Wd" rel="noreferrer" target="_blank">https://godbolt.org/g/SXc4Wd</a><br>
<br>
  void test_int () {<br>
      int b;<br>
      static_assert(noexcept(b &= b), "" );<br>
  }<br>
  void test_byte () {<br>
      std::byte b;<br>
      static_assert(noexcept(b &= (std::byte &)b), "" );<br>
  }<br>
<br>
  <source>:4:30: warning: explicitly assigning value of variable of type 'int' to itself [-Wself-assign]<br>
<br>
      static_assert(noexcept(b &= b), "" );<br>
<br>
                             ~ ^  ~<br>
<br>
Should it really warn when in unevaluated context?<br>
Dunno, but trunk already does that. Should that be changed?<br>
<br>
Which other large codebase do you want me to evaluate, so we can talk facts?<br></blockquote><div><br></div><div>Either of OpenOffice, Firefox, or Chromium have been used in the past for warning evaluation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">>> (as for the flag splitting - that was sometimes done if the new variant of<br>
>>  a flag had enough bug-finding power that an existing codebase using the<br>
>>  existing flag behavior would need significant cleanup - by having the new<br>
>>  functionality under another flag name, existing codebases upgrading to a<br>
>>  newer compiler wouldn't be forced to either do all that cleanup up-front or<br>
>>  disable the flag & risk regressions... )<br>
<br>
<br>
<br>
<br>
Repository:<br>
  rC Clang<br>
<br>
<a href="https://reviews.llvm.org/D44883" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D44883</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>