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

Kim Gräsman kim.grasman at gmail.com
Fri Aug 1 01:07:36 PDT 2014


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?

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/bbc5d1b8/attachment.html>


More information about the cfe-dev mailing list