<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 16, 2013 at 5:51 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank" class="cremed">eli.friedman@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="HOEnZb adM"><div class="im">> 1. Decide whether or not we want such capabilities (if we do not we may just<br>

> add sporadically the support for a new warning/group of warning/error).<br>
> 2. Come up with a plan to implement that (assuming we want it).<br>
<br>
</div></div>The frontend should be presenting warnings, not the backend; adding a<br>
hook which provides the appropriate information shouldn't be too hard.<br>
 Warnings coming out of the backend are very difficult to design well,<br>
so I don't expect we will add many.  Also, keep in mind that the<br>
information coming out of the backend could be used in other ways; it<br>
might not make sense for the backend to decide that some piece of<br>
information should be presented as a warning.  (Consider, for example,<br>
IDE integration to provide additional information about functions and<br>
loops on demand.)<br>
<br>
-Eli</blockquote></div><br>I really like this design, where essentially the frontend can query the backend for very simple information using a nice API, and then emit the warning itself. I'm happy for the warning to be in the CodeGen layer of the frontend, and only be reachable when generating code for that function body.</div>
</div>