<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 11:01 AM, Andy Gibbs <span dir="ltr"><<a href="mailto:andyg1001@hotmail.co.uk" target="_blank">andyg1001@hotmail.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday, December 3, 2015 6:55PM, David Blaikie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We still have Clang that (arguably) correctly implements the warning without<br>
the friend exception that GCC implements.<br>
<br>
My basic bar would be: Either we consider GCC's behavior correct and we fix<br>
Clang's warning to do the same (& keep your code change). Or we consider<br>
GCC's behavior to be incorrect and we undo this change and disable GCC's<br>
warning.<br>
</blockquote>
<br></span>
Ok, but the downside of this approach is that ultimately (a bit hyperbolic<br>
I grant you) we end up disabling all of GCC's warnings and trust only to<br>
clang's.  I think this is a dangerous approach - even with all the confidence<br>
I have in clang getting things right.</blockquote><div><br></div><div>Sounds like a slippery slope fallacy, no?<br><br>We know there's a flaw in this diagnostic here, so we disable it. In some cases we may find the GCC diagnostic is superior and that we should fix Clang instead. In many cases the diagnostics have obvious behavior and either initially, or after some iteration, they match behavior between the two compilers.<br><br>(for another example of a divergence, where we disable the GCC diagnostic, see the overloaded-virtual warning disabling, if I recall correctly)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My usual reason to push back against changes like this is the precedent -<br>
I don't want us to keep making sub-optimal changes to placate a warning.<br>
Death by a thousand cuts & all that (though there's probably only tens of<br>
cases of non-virtual dtors in polymorphic hierarchies across LLVM and Clang,<br>
to be fair)<br>
</blockquote>
<br></span>
Heh, maybe (given the precise impact here) tens of thousands!  But I take<br>
your point.  I certainly wouldn't dare get into an argument about anything to<br>
do with "optimal" -- I have a coding partner who delights in shouting<br>
"premature optimisation" at me at the slightest provocation :o)</blockquote><div><br></div><div>Yep, there's a fine line between premature optimization and premature pessimization. The same line that causes us to pass std::strings by const ref (or StringRef) rather than by value, for example. And not everyone draws the line in the same place, for sure.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd rather discuss these things & come to an understanding/agreement, but<br>
if a request is simpler, I think this change should be reverted and, if<br>
you'd like to keep the GCC build warning-clean, a patch to disable this<br>
warning would be acceptable. Clang's warnings will continue to catch the<br>
other cases & self-hosting buildbots will flag them soon enough.<br>
</blockquote>
<br></span>
Well, I've stated my case, but I'm more than happy to revert the change since<br>
your involvement and experience in the project is vastly superior to mine :o)<br>
<br>
Anyway, I'm at home now, so I won't be able to do it before tomorrow.</blockquote><div><br></div><div>Sure sure, no rush.<br><br>- Dave </div></div></div></div>