rnk added a comment. In https://reviews.llvm.org/D53457#1269769, @hans wrote:
> I haven't started looking at the code yet. > > I'm not completely convinced that we want this. So far we've used the > strategy of promoting clang options that are also useful in clang-cl to core > options, and if someone wants to use more clang than that, maybe clang-cl > isn't the right driver for that use-case. > > But I suppose an argument could be made for having an escape hatch from > clang-cl if it doesn't add too much complexity to the code. Personally, I really want to get out of the role of being a gatekeeper for GCC-style driver flags. I want users to be able to solve their own problems without building clang-cl from scratch or waiting for the next 6 month release. I'm personally in favor of moving clang-cl to a blacklist model instead of a whitelist model so that we go even further in this direction, but it doesn't address what to do about conflicting or ambiguous options like `-MD`. An escape hatch like `[-/]Xdriver:` seems like a useful thing to have when that arises. > I'm not sure I'm a fan of calling it /Xdriver: though, because what does it > mean - clang-cl is the driver, but the option refers to the clang driver. The > natural name would of course be -Xclang but that already means something > else. Maybe we could just call it /clang: Huh, I like that. You'd also be able to spell it `-clang:`, so the leading `/` is less of a disambiguator, but the colon is clearly a sign that this is a CL-style option. Repository: rC Clang https://reviews.llvm.org/D53457 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
