[PATCH] clang-cl: Add the /c, /W0 and /W1 options

[Chandler Carruth]

================
Comment at: include/clang/Driver/CLCompatOptions.td:24
@@ +23,3 @@
+  HelpText<"Display available options">;
+def _SLASH_W0 : CLFlag<"W0">, HelpText<"Disable all warnings">;
+def _SLASH_W1 : CLFlag<"W1">, HelpText<"Enable -Wall">, Alias<Wall>;
----------------
shouldn't this be an alias for '-w'?

================
Comment at: lib/Driver/WindowsToolChain.cpp:351
@@ +350,3 @@
+      break;
+    case options::OPT__SLASH_W1:
+      Alias = "all";
----------------
Reid Kleckner wrote:
> Is it necessary to have this custom handling for aliased options?  I was hoping to limit the custom handling to things that can't be expressed as simple aliases like -W0.
I don't understand why all of these can't be handled with aliases, and no hand authored C++ code.

================
Comment at: lib/Driver/WindowsToolChain.cpp:362-367
@@ +361,8 @@
+
+DerivedArgList *Windows::TranslateArgs(const DerivedArgList &Args,
+                                       const char *BoundArch) const {
+  DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
+  const OptTable &Opts = getDriver().getOpts();
+
+  // Only options in cl_Group would need translation.
+  for (ArgList::const_iterator it = Args.begin(), ie = Args.end(); it != ie;
----------------
I generally don't like this approach.

For the overwhelming majority of cases, we should be able to use aliases to handle things.

For the rest, we should handle matching the CL options and generating the CC1 options the same way we handle all of the GCC-compatibility options: in a domain specific way where we scrape the driver for any of the relevant options and then build the canonical way to hand down the information to CC1.


http://llvm-reviews.chandlerc.com/D1232