<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.<span class=""><br>
<br>
<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)<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, </blockquote><div><br></div><div>& thank you for doing so - I really would like it if there were more voices to discuss these things. Often feels a bit too quiet when I try to have a discussion about them & there aren't (m)any other voices/perspectives.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div>FWIW, you can probably find an old thread I tried to have about some similar/related API quirks in the Clang Tooling codebase & I didn't get so far trying to explain my perspective to another LLVM contributor... *shakes head* my perspectives certainly aren't universally accepted, even across the LLVM project.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anyway, I'm at home now, so I won't be able to do it before tomorrow.<br>
<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
Andy <br>
</font></span></blockquote></div><br></div></div>