thakis added a comment.
Comment from the peanut gallery:
- I like the whitelist model for gcc-style flags. It allows us to curate them
(and `/?` output) since many don't make much sense in the cl world.
- I like the idea behind this patch (and /clang: seems like a good spelling)
Repository:
hans added a comment.
In https://reviews.llvm.org/D53457#1271046, @neerajksingh wrote:
> 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 t
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 th
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 s
hans added a comment.
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
neerajksingh created this revision.
neerajksingh added reviewers: rnk, hans.
The clang-cl driver disables access to command line options outside of the
"Core" and "CLOption" sets of command line arguments. This filtering makes it
impossible to pass arguments that are interpreted by the clang drive
