[cfe-dev] Controlling delayed template parsing via pragma

Reid Kleckner rnk at google.com
Mon Mar 3 21:39:17 PST 2014


I'm kind of torn.  I can see why users would want to switch between SDK
header parsing mode and user code parsing mode for more conforming
diagnostics, but I worry about the support burden of allowing the template
parsing mode to switch halfway through the TU.  General opinion among
colleagues seemed to be that less state and fewer pragmas is better.

I'd rather make it to a world where we don't have non-conforming headers
than a world where we have pragmas and complex include-shadowing systems to
work around non-conforming headers, but maybe that's too idealistic.


On Mon, Mar 3, 2014 at 11:41 AM, Nico Rieck <nico.rieck at gmail.com> wrote:

> Currently delayed template parsing is enabled by default for Windows
> because some Windows SDK headers and ATL require it (though forward
> declaring "struct IUnknown;" seems to suffice for large parts of the
> SDK, including 3D and multimedia). As it is implemented, delayed
> template parsing is all-or-nothing and user code is forced to accept the
> relaxed parsing rules.
>
> I have been toying with the idea to make delayed template parsing
> controllable via pragma so it can be enabled just for offending headers.
> This pragma might take the following form with the default state
> determined by -fdelayed-template-parsing:
>
>   #pragma delayed_template_parsing(push, [on|off])
>   #pragma delayed_template_parsing(pop)
>
> This would be the first pragma to not delegate to Sema because this must
> be handled in the parser.
>
> Before I clean it up and put out a patch I'd like to get some feedback
> on whether this direction taken is acceptable.
>
> -Nico
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140303/59095160/attachment.html>


More information about the cfe-dev mailing list