[cfe-dev] [PATCH] MS compatibility flag implies delayed parsing

[Aaron Ballman]

On Tue, Nov 15, 2011 at 1:39 PM, Francois Pichet <pichet2000 at gmail.com> wrote:
> On Tue, Nov 15, 2011 at 2:27 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> On Tue, Nov 15, 2011 at 1:20 PM, Ruben Van Boxem
>> <vanboxem.ruben at gmail.com> wrote:
>>> Hold your horses! Win32 != borked MSVC headers! There's also GCC for
>>> windows, and as I don't know what implications the delayed template parsing
>>> has on the libstdc++/libc++ headers, it's not a good idea to make this a
>>> default for Win32.
>>
>> We're talking about -fms-compatibility, which does = borked MSVC
>> headers, which generally require delayed template parsing.  That's why
>> the discussion is happening about making -fms-compatibility
>> automatically adding -fdelayed-template-parsing.
>>
>> ~Aaron
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> I think this is very a theoretical discussion, in practice both
> -fdelayed-template-parsing and -fms-compatibility options are passed
> by the driver to the -cc1 clang internal spawning if the triple is
> Win32. For GCC on Windows there is a different MinGW32 triple.

After a discussion on IRC, it sounds like the current patch would be
acceptable as-is.  But I agree with Francois that this is more
theoretical than I was originally thinking.  It sounds like this patch
would be helpful for people using a clang build that was not made with
Visual Studio (MinGW, et al), but want to target the Windows platform
SDK headers (instead of the MinGW headers, for instance).  I don't
think this is a huge audience.

If there are continued reservations, I'm happy to let the patch drop.
If people think there's use from the patch, it sounds like it may be
good to go.

~Aaron