[cfe-dev] Tooling vs -fdelayed-template-parsing WAS: Clang-cl.exe and the VC++ preprocessor

[Reid Kleckner]

On Fri, Aug 1, 2014 at 1:07 AM, Kim Gräsman <kim.grasman at gmail.com> wrote:

> On Tue, Jul 15, 2014 at 10:01 PM, Reid Kleckner <rnk at google.com> wrote:
>
>>
>> [...] 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.
>>
>
> We're struggling with delayed template parsing in our IWYU tool, so this
> caught my eye.
>
> This fragment:
>
>   #include "tests/cxx/direct.h"
>
>   template <typename T> void foo() {
>       IndirectClass ic;
>   }
>
> (from https://code.google.com/p/include-what-you-use/issues/detail?id=129)
>
> 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.
>

>
We've considered always running IWYU with -fno-delayed-template-parsing,
> but that would probably make parsing of Microsoft system headers fail
> entirely.
>
> Are we stuck here? Or is there a workaround for visiting template bodies
> even under -fdelayed-template-parsing?
>

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. :)


> Clang-modernize seems to have run into the same problem, so this might
> become more of a problem as tools start supporting Windows:
>
> http://clang.llvm.org/extra/PassByValueTransform.html#note-about-delayed-template-parsing
>
> 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.
>
> - Kim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140801/169a0fb7/attachment.html>