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

[Ruben Van Boxem]

Op 15 nov. 2011 20:24 schreef "David Blaikie" <dblaikie at gmail.com> het
volgende:
>
> On Tue, Nov 15, 2011 at 11:20 AM, Ruben Van Boxem
> <vanboxem.ruben at gmail.com> wrote:
> > Op 15 nov. 2011 20:04 schreef "David Blaikie" <dblaikie at gmail.com> het
> > volgende:
> >
> >>
> >> On Tue, Nov 15, 2011 at 10:50 AM, Aaron Ballman <aaron at aaronballman.com
>
> >> wrote:
> >> > On Tue, Nov 15, 2011 at 11:49 AM, David Blaikie <dblaikie at gmail.com>
> >> > wrote:
> >> >> On Tue, Nov 15, 2011 at 7:49 AM, Francois Pichet <
pichet2000 at gmail.com>
> >> >> wrote:
> >> >>> On Mon, Nov 14, 2011 at 8:46 PM, Aaron Ballman
> >> >>> <aaron at aaronballman.com> wrote:
> >> >>>> On Mon, Nov 14, 2011 at 5:53 PM, Francois Pichet
> >> >>>> <pichet2000 at gmail.com> wrote:
> >> >>>>> This doesn't work.
> >> >>>>> Some tests depend on -fno-delayed-template-parsing to exist at
the
> >> >>>>> driver level.
> >> >>>>
> >> >>>> Good catch!  I've revised the patch so that
> >> >>>> -fno-delayed-template-parsing will be honored in the driver.
> >> >>>
> >> >>> Having option -fno-delayed-template-parsing without
> >> >>> -fdelayed-template-parsing doesn't sound right to me.
> >> >>> How about we keep it.
> >> >
> >> > Are you suggesting we keep the flag, but still make it implicitly on
> >> > when ms-compatibility is specified?  Or just keep things as they are
> >> > today?  I am fine with keeping the flag, but I still think we should
> >> > implicitly turn it on for ms-compatibility.
> >> >
> >> >> Shouldn't those tests that are currently using
> >> >> -fno-delayed-template-parsing be modified to use -fms-compatibility
or
> >> >> pass -fno-delayed-template-parsing via -Xclang? Or are those test
case
> >> >> enough to justify the existence of -fno-delayed-template-parsing as
a
> >> >> driver-visible flag?
> >> >
> >> > I usually figure that if there's a test for it, there's a reason for
> >> > it, so I think they do justify the ability to turn off delayed
> >> > template parsing explicitly.
> >>
> >> My best guess, glancing at the tests, is that the switch was used to
> >> make the tests portable - probably just because the switch existed and
> >> was the smallest change necessary to get the tests to pass across
> >> platforms. It doesn't look like there would be a problem with just
> >> -fno-ms-compatibility being used entirely for those tests but  I'm
> >> open to suggestions.
> >>
> >> In fact they were pretty much all added in r138942 by Francois:
> >>
> >> "Enable -fdelayed-template-parsing by default on Win32.
> >> I had to force -fno-delayed-template-parsing on some Index tests
> >> because delayed template parsing will change the output of some
> >> tests."
> >>
> >> So presumably if we make -fms-compatibility default on in Win32 (which
> >> if we haven't already, we probably should if it's going to subsume
> >> -fdelayed-template-parsing) then it make sense to just change these
> >> all to -fno-ms-compatibility.
> >
> > 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.
>
> Perhaps you misunderstood - delayed template parsing already is the
> default in windows & has been for a couple of months.

Wow, OK. Didn't realize that. I assumed ms-compatibility == implement
"features" needed to parse MSVC headers.

If I may ask, what could delayed template parsing do on other platforms? I
noticed a post about a 5% speed increase when the option is used

Ruben

>
> - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111115/f600e58d/attachment.html>