<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 6, 2015 at 2:08 PM, Paul Fultz II <span dir="ltr"><<a href="mailto:pfultz2@yahoo.com" target="_blank">pfultz2@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> gives the user no idea of how we got from a call to f into a call to g.<br><br>
For the default case, its better to show the first and last in the trace, as most users don't care about the intermediate steps.<br>
<span class=""><br>
> If we produced a stack of 'in instantiation of' notes, this would be fine<br>
<br>
</span>Yes, the full back trace can be added in the future(perhaps as a compiler flag). This is the first step towards that direction. There needs to be some refactoring to `DeductionFailureInfo` so it stores the entire diagnostics(rather than a single diagnostic) to make a full back trace possible.</blockquote><div><br></div><div>The difference is, the current diagnostics allow the user to figure out what happened. This change does not -- there's no way to find out which 'f' caused the problem, and how we got from 'f' to 'g'. Hence this patch is not acceptable as-is -- not even as a stepping stone to something better.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> note that's exactly what my patch in comment#1/comment#2 of that bug does<br>
<br>
</span>That seemed to be more of a hack then something to be used in production.</blockquote><div><br></div><div>Yes, absolutely, that change is not production-ready.</div></div></div></div>