<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 23, 2015, at 11:04 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" class="">rafael.espindola@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">How is it not a viable fight? Is the section attribute coming from a completely different place? Or are you suggesting that it is never viable to tell people that they ought to fix their code, no matter how unnecessarily perverse it is? A section should be an intrinsic part of an definition, saying that you can’t define the same thing in multiple inconsistent ways is not even slightly unreasonable.</div></div></blockquote><div class=""><br class=""></div><div class="">The bug first got reported to us while trying to build glibc. The bug Richard noticed was fixed in gcc because it was breaking the linux kernel. If anyone thinks it is productive to try to get them to change, go for it.</div></div></div></div></div></blockquote><div><br class=""></div><div>Sorry, do these open-source projects no longer accept patches? Adding section attributes after a definition does not seem defensible to me, and I would guess that the declarations are actually in the same file, just in the wrong order.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">“Build everything GCC can without modification” has never been a fundamental requirement for clang, though, and that appears to be your standard.</div><div class=""><br class=""></div><div class="">PR16187 is an example that I would feel fairly comfortable diagnosing. You could certainly construct a more challenging example, though.</div><div class=""><span class=""><br class=""></span></div></div></blockquote><div class=""><br class=""></div><div class="">It is an example where we *were* diagnosing. Except that then we cannot build firefox or chrome. You are also more than welcome to get them to change because you don't like how gcc implemented an extension.</div></div></div></div></div></blockquote><div><br class=""></div><div>There are ways to work with projects so that you can carefully roll out a diagnostic without completely shutting down development for everyone. This is a danger literally every time we add a warning. We’re not going to stop adding warnings.</div><div><br class=""></div></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">>You’ll need to remind me what it is that we can’t implement here.</div><div class=""><br class=""></div><div class="">test/SemaCXX/anonymous-struct.cpp</div></div></div></div></blockquote><div><br class=""></div>You will note that IRGen is not computing the linkage in this Sema test. Linkage is a semantic property that the type-checker inherently has to care about. We can support this (by delaying the diagnostic about specializing on internal types) without changing anything in IRGen, but only by not caching linkage, either.</div><div><br class=""></div><div>John.</div></body></html>