On Wed, Jul 11, 2012 at 1:40 PM, Richard Smith <[email protected]>wrote:
> On Wed, Jul 11, 2012 at 1:33 PM, Chandler Carruth <[email protected]>wrote: > >> On Wed, Jul 11, 2012 at 1:31 PM, Nico Weber <[email protected]> wrote: >> >>> I have another patch locally that changed it there, but the driver has a >>> comment that says "to do: move language stuff from frontend to driver". >>> On Jul 11, 2012 10:21 PM, "Richard Smith" <[email protected]> >>> wrote: >>> >>>> Is there a reason to put the change there rather than in >>>> CompilerInvocation::setLangDefaults? It seems like this would do the wrong >>>> thing for tools which don't use the driver. >>>> >>> >> Put another way, tools which don't use the driver will be quite broken in >> other ways too (builtin header search). The new tooling stuff should always >> round trip through the driver. >> > > I don't think this addresses my main concern. We used to have one place > where the default -std= was set. We now have two, and one of them is not > easy to discover. If we don't have a good reason to split this up, it > should all be handled in the same place. > The reason is to migrate all of them to the driver. There is already logic for handling -std= in the driver that would be relevant to setting the default as well. I would like there to be no further work on in-Frontend flag management, and instead focus on moving it to the driver. I'm happy to see the rest of that routine move the driver too, as then I agree we will have only one place responsible for this.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
