<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 22, 2013, at 2:25 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank" class="cremed">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>> This is pretty much the same as what Quentin proposed (with the addition of the enum), isn't it?<br>
>><br>
><br>
> Pretty close yeah.<br>
><br>
<br>
</div>Another thought and alternate strategy for dealing with these sorts of things:<br>
<br>
A much more broad set of callback machinery that allows the backend to<br>
communicate values or other information back to the front end that can<br>
then decide what to do. We can define an interface around this, but<br>
instead of having the backend vending diagnostics we have the callback<br>
take a "do something with this value" which can just be "communicate<br>
it back to the front end" or a diagnostic callback can be passed down<br>
from the front end, etc.<br>
<br>
This will probably take a bit more design to get a general framework<br>
set up, but imagine the usefulness of say being able to automatically<br>
reschedule a jitted function to a thread with a larger default stack<br>
size if the callback states that the thread size was N+1 where N is<br>
the size of the stack for a thread you've created.</blockquote></div><br>FWIW, *this* is what I was trying to get across. Not that it wouldn't be a callback-based mechanism, but that it should be a fully general mechanism rather than having something to do with warnings, errors, notes, etc. If a frontend chooses to use it to produce such diagnostics, cool, but there are other use cases that the same machinery should serve.</div>
</div></blockquote><br></div><div>How about this: keep the jist of the current API, but drop the "warning"- or "error"-ness of the API. Instead, the backend just includes an enum value (plus string message for extra data). The frontend makes the decision of how to render the diagnostic (or not, dropping them is fine) along with how to map them onto warning/error or whatever concepts they use.</div><div><br></div><div>-Chris</div><br></body></html>