<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 1, 2014 at 1:07 AM, Kim Gräsman <span dir="ltr"><<a href="mailto:kim.grasman@gmail.com" target="_blank">kim.grasman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
On Tue, Jul 15, 2014 at 10:01 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>[...] I don't think we're getting a lot of value out of -fdelayed-template-parsing.  The only thing we get out of it is the ability to do unqualified lookup of names that haven't been declared yet in the global namespace.  Because we still use our TreeTransform approach to template instantiation, most of the parsing difficulty is handled by -fms-compatibility hacks and not -fdelayed-template-parsing.  The MS compatibility hacks are actually better because they usually appear in error codepaths, meaning they don't affect compilation performance and are easy to diagnose with a warning, instead of -fdelayed-template-parsing where we can't know if the user relies on it.</div>


</div></div></div>
</blockquote></div><br></div><div class="gmail_extra">We're struggling with delayed template parsing in our IWYU tool, so this caught my eye.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This fragment:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">  #include "tests/cxx/direct.h"</div><div class="gmail_extra"><br></div><div class="gmail_extra">  template <typename T> void foo() {</div>

<div class="gmail_extra">      IndirectClass ic;</div><div class="gmail_extra">  }</div><div><br></div><div>(from <a href="https://code.google.com/p/include-what-you-use/issues/detail?id=129" target="_blank">https://code.google.com/p/include-what-you-use/issues/detail?id=129</a>)</div>

<div><br></div><div>will have IWYU suggest removal of the #include in MSVC-compatible mode only (because of -fdelayed-template-parsing). In 'normal' mode, the template gets an AST built for it, and the IndirectClass use is properly detected. </div>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div> </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div>We've considered always running IWYU with -fno-delayed-template-parsing, but that would probably make parsing of Microsoft system headers fail entirely.</div><div><br></div><div>Are we stuck here? Or is there a workaround for visiting template bodies even under -fdelayed-template-parsing?</div>
</div></div></blockquote><div><br></div><div>Hypothetically you could record every late parsed function decl (FD->isLateTemplateParsed()) and call LateTemplateParser on it at the end of the TU.  This would get you the uninstantiated template AST, which is what you want. I make no guarantees, though. :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div>Clang-modernize seems to have run into the same problem, so this might become more of a problem as tools start supporting Windows:</div>
<div><a href="http://clang.llvm.org/extra/PassByValueTransform.html#note-about-delayed-template-parsing" target="_blank">http://clang.llvm.org/extra/PassByValueTransform.html#note-about-delayed-template-parsing</a><br>
</div><div><br></div><div>So your approach sounds interesting, to treat delayed template parsing as an error path. It would fix the vast majority of these RAV problems in portable codebases, and code that relies on delayed parsing would still compile, even if it would be silently missed in RAV.</div>
<span class=""><font color="#888888">
<div><br></div><div>- Kim</div></font></span></div></div>
</blockquote></div><br></div></div>