<div dir="ltr">LGTM, but you should get an OK from Chandler since this was basically his idea.<div><br></div><div>On Tue, Jul 23, 2013 at 5:58 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On Tue, Jul 23, 2013 at 10:56 AM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> I think we want to have a whitelist of "clang options" that are distinct<br>
> from gcc options, rather than blacklisting a troublesome few (-MD) as<br>
> GCCOptions.  That seemed to be the main conclusion of the discussion on<br>
> cfe-dev.<br>
<br>
</div>I thought for a while that blacklisting "a troublesome few" would make<br>
for a much shorter list than whitelisting "clang options", but now<br>
that I look at the file again, I see that there's a very large amount<br>
of options that don't apply to clang-cl, and lots of conflicts too.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I've attached a new patch that does the whitelist approach, and starts<br>
with a pretty short whitelist. I figure we can add more stuff too it<br>
as needed.</blockquote><div><br></div><div><div>I agree, I think the risk of exposing too much is greater than the risk of exposing too little, in which case we just add it and the user can work around it with -Xclang.</div>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> We obviously don't want to add Flags<[ClangOption]> to every option in<br>
> f_Group and f_clang_Group, so there'll have to be some tablegen magic in<br>
> there.<br>
<br>
</div>I'm not sure we want to whitelist everything in f_Group and<br>
f_clang_Group, though. For example, -fapple-kext is in f_Group, which<br>
doesn't make sense for clang-cl. In g_clang_Group we have the<br>
sanitizer options, maybe we want to hold off exposing those options<br>
until we support them? There's also -fno-inline, which maybe we don't<br>
want to expose since clang-cl will have /Ob0?<br></blockquote><div><br></div><div>Timur can probably speak more about asan support for Windows.  IMO the sanitizers are some of the cooler clang/LLVM features available, so I'd like to be able to get at them through this driver even if they're broken.</div>
<div><br></div><div>I imagine sanitizer integration testing on Windows is going to end up using clang-cl so clang can be dropped into an existing build system.</div><div><br></div></div></div></div></div>