Sink the strange '-stdlib=...' flag handling into the C++ include

handling logic of the generic ToolChain. This flag, despite its name,
has *nothing* to do with the GCC flag '-nostdlib' that relates
(exclusively) to the linking behavior. It is a most unfortunate name in
that regard...

It is used to tell InitHeaderSearch.cpp *which* set of C++ standard
library header search paths to use -- those for libstdc++ from GCC's
installation, or those from a libc++ installation. As this logic is
hoisted out of the Frontend, and into the Driver as part of this
ToolChain, the generic method will be overridden for the platform, where
it can implement this logic directly. As such, hiding the CC1 option
passing in the generic space is a natural fit despite the odd naming.

Also, expand on the comments to clarify whats going on, and tidy up the
Tools.cpp code now that its simpler.

llvm-svn: 143687

1 files changed, 1 insertions, 4 deletions

diff --git a/clang/lib/Driver/Tools.cpp b/clang/lib/Driver/Tools.cpp
index 47521c41a21..4f84d0a0dd2 100644
--- a/clang/lib/Driver/Tools.cpp
+++ b/clang/lib/Driver/Tools.cpp
@@ -425,11 +425,8 @@ void Clang::AddPreprocessingOptions(const Driver &D,
   getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
 
   // Add C++ include arguments, if needed.
-  types::ID InputType = Inputs[0].getType();
-  if (types::isCXX(InputType)) {
+  if (types::isCXX(Inputs[0].getType()))
     getToolChain().AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
-    Args.AddAllArgs(CmdArgs, options::OPT_stdlib_EQ);
-  }
 }
 
 /// getARMTargetCPU - Get the (LLVM) name of the ARM cpu we are targeting.