[PATCH] SanitizerArgs: add ability to filter/diagnose unsupported sanitizers.

[Peter Collingbourne]

================
Comment at: lib/Driver/SanitizerArgs.cpp:56
@@ +55,3 @@
+    // Avoid diagnosing any sanitizer which is disabled later.
+    Add &= ~AllRemove;
+    // At this point we have not expanded groups, so any unsupported sanitizers
----------------
Richard Smith wrote:
> Hmm, should we mask out `AllAdd` here too? We don't want to issue two diagnostics for `-fsanitize=bad -fsanitize=bad`. But on the other hand diagnosing `-fsanitize=bad -fsanitize=group-including-bad` might be nice. Ugh. Maybe what we want is a limit of one diagnostic per problem?
Yes, masking out AllAdd doesn't seem like it will work trivially.  Deduplicating in filterUnsupportedMask by accumulating a mask of diagnosed kinds seems to work, although (as the new test shows) we don't give the best diagnostics in the world sometimes.

================
Comment at: lib/Driver/SanitizerArgs.cpp:132-135
@@ -109,6 +131,6 @@
   // command line).
-  if ((Kind & AddressFull) != 0 && (AllKinds & Address) == 0)
+  if ((Kind & AddressFull) != 0 && (AllAdd & Address) == 0)
     D.Diag(diag::warn_drv_unused_sanitizer)
      << lastArgumentForKind(D, Args, AddressFull)
      << "-fsanitize=address";
 
----------------
Richard Smith wrote:
> This looks a bit strange. We won't diagnose
> 
>   -fsanitize=address -fno-sanitize=address -fsanitize=init-order
> 
> Following the principle of later arguments overriding earlier ones, I would have expected a diagnostic for that, but not for:
> 
>   -fsanitize=address -fsanitize=init-order -fno-sanitize=address
> 
> Seems to be a pre-existing oddness, though.
*shrug* I'll let Alexey comment on this, as he introduced this behavior in r173670.


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