[cfe-dev] Clang-cl.exe and the VC++ preprocessor

[Reid Kleckner]

On Tue, Jul 15, 2014 at 10:57 AM, Nico Rieck <nico.rieck at gmail.com> wrote:

> On 12.07.2014 12:07, Alp Toker wrote:
> > It sounds like the request in this thread boils down to extending
> > MSVCCompat to support more standards-compliance outside of system
> > headers. In other words, parsing Microsoft headers and retaining VC++
> > ABI but not imposing those quirks on user code:
> >
> > We already try to do a lot of that on the semantic analysis level, a few
> > sporadic attempts in the parser, but AFAIK not yet any attempt to do so
> > in the preprocessor.
>
> It would be nice if all (or most) of these compatibility quirks could be
> isolated to specific headers. The last time I proposed something in this
> direction (see [1]) it quickly got shot down and didn't garner any
> further reactions. There seems to be reluctancy to add further state to
> the parser which directly goes against these suggestions.
>
> [1]: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-March/035738.html


I am open to reevaluating that decision.   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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140715/7c065cb5/attachment.html>