<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 January 2015 at 13:09, Porkolab Zoltan <span dir="ltr"><<a href="mailto:gsd@caesar.elte.hu" target="_blank">gsd@caesar.elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi all,<br>
<br>
First of all, Nick: many thanks for helping us. Mikael did a huge work refactoring templight and now there are even clients eager to use it:<br>
<a href="https://github.com/sabel83/metashell" target="_blank">https://github.com/sabel83/<u></u>metashell</a><span><br>
<br>
On Tue, 6 Jan 2015, Nick Lewycky wrote:<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
On 11 March 2014 18:28, Mikael Persson <<a href="mailto:mikael.s.persson@gmail.com" target="_blank">mikael.s.persson@gmail.com</a>> wrote:<br>
<br></span><span>
Hi Mikael,<br>
<br>
Sorry to lead with this, but it's important. The llvm project requires that<br>
patches be submitted by their author (or authors). If you grabbed the<br>
original templight code and refactored it, then it may be coauthored between<br>
you and the original authors. Our policy requires that an author submit<br>
their own code, not mail in someone else's,<br>
see <a href="http://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes" target="_blank">http://llvm.org/docs/<u></u>DeveloperPolicy.html#<u></u>attribution-of-changes</a> for<br>
specifics.<br>
</span></blockquote>
<br>
We completely support Mikael's work on refactoring the original templight. Naturally, we happy to adopt Mikael as a co-author or give him any kind of<br>
authorization to submit this patch.</blockquote><div><br></div><div>That is good to hear!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">      Changes to existing Clang code-base:<br>
<br>
</blockquote>
<br></span>
[...]<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 (5) Added callbacks for begin / end of template instantiations. These<br>
were added in all the places where the original Templight code had<br>
templight calls. This replaces the original templight tracing calls.<br>
<br>
<br>
At a high level, I think that what we currently do in Sema by tracking<br>
template instantiations as a stack (Sema::<u></u>ActiveTemplateInstantiations)<br>
should be available in the AST after instantiation is complete. Then we<br>
could query the AST to ask why something was instantiated instead of tracing<br>
the act of instantiation. Is there any use case for templight where this<br>
wouldn't work?<br>
</blockquote>
<br></span>
Don't forget, this is a template debugger and profiler function.<br></blockquote><div><br></div><div>Got it. I did forget about profiling.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As a debugger we want to follow the chain of template related events even if the instantiation was not successfully finished. Unpaired begin-end instantiation events may happen and are reported in templight.</blockquote><div><br></div><div>I'm not sure what you're describing. Do these ever occur in a way that is not a bug in clang?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Moreover, this strategy allows templight to work in "safe mode": emitting events immediatelly as they happened. This way we have the last events even if the compiler crashes - which unfortunatelly may happen for template metaprograms.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As a profiler templight assigns timestamps for beginning/end events to measure the time clang has spent on that instantiation.<br></blockquote><div><br></div><div>I think a template debugger would be a great new major feature for clang, and I've heard requests for it in person. However, it seems that different people have different ideas of what exactly "template debugger" means. I don't know of any effort which is farther along than templight, which suggests that you have real uses for template debugging rather than hypothetical users.</div><div><br></div><div>Nick</div></div><br></div></div>