<div dir="ltr"><div class="gmail_extra">Sorry for the delays, just haven't been able to get back around to this. My silence isn't about not caring.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 5:13 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank" class="cremed">qcolombet@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Like I summed up in my previous email (see below), there are two orthogonal approaches to this problem.</div><div>
I have chosen the second one (extend the reporting already used for inline asm).</div><div><br></div><div>Regarding the first approach (front-end querying the back-end to build up diagnostic), it needs further discussion if anyone wants to go in that direction. Although I think this is interesting, I leave that for someone else.</div>
</blockquote></div><br>I really don't like the second approach.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fundamentally, it increasingly couples LLVM to Clang's warning infrastructure and I think that's a bad thing. I think we are better served by designing good interfaces for the frontend and the backend to communicate in order for different frontends to provide different types and kinds of information to users based on their needs.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Bob described one potential API for this, but I think there are much better ones. I don't think we have to be constrained by the idea of using a pass to compute and communicate this information -- there are other approaches. I haven't thought about them because I haven't designed such an interface. If I had, I would just contribute it. I do think that this is the correct design direction though, as I don't think that there is one unified way to represent diagnostics in the backend, or if there is I don't tihnk we have any idea what it looks like.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Inline assembly is more of a special case than anything else. I don't really see why the right path forward is to design a generic framework around what was originally built for its specific purpose.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If anything, I think the design you are pursuing is strictly more complex and invasive, and without any tangible benefits as a consequence.</div><div class="gmail_extra">
-Chandler</div></div>