neerajksingh added a comment. In https://reviews.llvm.org/D53457#1269769, @hans wrote:
> 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. This is a good point. However, having this escape hatch gets you and Reid and others out of the business of having to promote options. Also, as new flags are added to the compiler people might need one revision of the official builds to realize they need a flag and one revision to get the flag added to the binary release. This obviously isn't a problem for people building Clang from source, but it does add unnecessary friction as I found myself. > 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: At the conference last week I discussed this with Reid Kleckner. One of the options we discussed was trying to make things work such that -Xclang serves both purposes. We quickly decided that this wouldn't work. /clang: would be fine, but it might be more confusing since people will wonder what's the difference between /Xclang and /clang:. We could use something more verbose like /Xclang-driver:. I'd be happy to change the flag to whatever spelling will build consensus. 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
