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

<p>Ruben</p>
<p>><br>
> - David<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</p>