<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 2, 2018 at 8:05 AM Roman Lebedev via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">lebedev.ri added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D44883#1054326" rel="noreferrer" target="_blank">https://reviews.llvm.org/D44883#1054326</a>, @thakis wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D44883#1048751" rel="noreferrer" target="_blank">https://reviews.llvm.org/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>
I did run it on stage-2 of LLVM itself. The only 'false-positives' so far are already present in trunk:<br></blockquote><div><br>To clarify a little - "false positive" in the sense Nico (& I) are using it is "any case in which the warning fired on code that was already working as intended" (ie: where the warning didn't represent a real bug - or at least represent a confusing/surprising thing that would be worth/benefit from rewriting to some other less confusing form).<br><br>So the cases you found in the tests for certain self assignment would also be false positives. <br><br>Not necessarily enough to warrant/argue against moving forward on this warning, but they are imho, false positives for the purpose of discussions like this.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<br>
>> (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/D44883</a><br>
<br>
<br>
<br>
</blockquote></div></div>