MSVC compatible driver proposal

[rnk]

I’d like there to be a cl.exe compatible clang driver. I think the best way for this to work is to have the existing clang driver detect when it’s being invoked as cl.exe, similar to how clang++ vs. clang works today. For testing, there should be a -ccc-msvc option which turns on the same behavior.

Some relevant past discussion on this topic:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html

The priorities for the driver should be, in order:

1. Drop in compatibility with MSVC
2. Compatibility with the existing clang driver
3. Don’t change the meaning of existing gcc-style driver command lines (an argument with a / prefix is an input path, not an option)
4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options as much as possible

I think #2 is important so that cross-platform projects (like LLVM) won’t have to spell clang options like -fcolor-diagnostics or -Wc++11-extensions twice.

It’s important to know that there are a few conflicts with MSVC like -MD, -MT, and things like -Zi where clang accepts -Z as a joined option, so there needs to be a good solution for disambiguating them.

Previously people have discussed using the slash prefix to disambiguate between the MSVC and clang meanings, but since cl.exe accepts both - and / prefixes for all of its options, I don’t like this approach. There are probably many Unix expats out there on Windows consistently using dash-style option prefixes everywhere, like me.

I think clang should give a higher precedence to all MSVC options before falling back to gcc style options. To resolve conflicts, there will have to be an escape flag. I propose -Xclang-driver, which is similar to -Xclang, except that it gets interpreted by the driver. Hopefully Microsoft never adds an -Xclang-driver flag.

Going forwards, Microsoft will probably add more flags to cl.exe. If they do and they conflict, we should value drop in compatibility above backwards compatibility and interpret the option as MSVC does, requiring users to use the escape if they need the conflicting option.

I’ve attached patches for LLVM and clang to start implementing this. They’re pretty rough, but I really want to get something committed and iterate on it, even if I back up and completely rewrite with a separate OptTable. I’ve been testing the driver by renaming clang.exe to cl.exe and putting it in the cwd before running MSBuild. It currently fails due to UTF-16 response files and -Fo takes an output directory which needs -cc1 logic.

Thoughts?

parse-option-flags.diff (5.09 KB)

clang-cl.diff (23.6 KB)

[rnk]

Code comments can go on the phab issues or to the commit list threads:

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

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

[zygoloid]

I'd like there to be a cl.exe compatible clang driver. I think the best way
for this to work is to have the existing clang driver detect when it's being
invoked as cl.exe, similar to how clang++ vs. clang works today. For
testing, there should be a -ccc-msvc option which turns on the same
behavior.

Some relevant past discussion on this topic:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html

The priorities for the driver should be, in order:

1. Drop in compatibility with MSVC
2. Compatibility with the existing clang driver
3. Don't change the meaning of existing gcc-style driver command lines (an
argument with a / prefix is an input path, not an option)
4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options as
much as possible

I think #2 is important so that cross-platform projects (like LLVM) won't
have to spell clang options like -fcolor-diagnostics or -Wc++11-extensions
twice.

Hmm, would cross-platform projects use the cl.exe-compatible driver?

It's important to know that there are a few conflicts with MSVC like -MD,
-MT, and things like -Zi where clang accepts -Z as a joined option, so there
needs to be a good solution for disambiguating them.

Previously people have discussed using the slash prefix to disambiguate
between the MSVC and clang meanings, but since cl.exe accepts both - and /
prefixes for all of its options, I don't like this approach. There are
probably many Unix expats out there on Windows consistently using dash-style
option prefixes everywhere, like me.

I think clang should give a higher precedence to all MSVC options before
falling back to gcc style options. To resolve conflicts, there will have to
be an escape flag. I propose -Xclang-driver, which is similar to -Xclang,
except that it gets interpreted by the driver. Hopefully Microsoft never
adds an -Xclang-driver flag.

It sounds like your mental model is that we have a "Clang driver", and
a set of extensions for a "cl.exe-compatible driver". I think it might
be a better perspective to think about this as a "g++-compatible
driver" and a "cl.exe-compatible driver". I guess what I'm saying is
that I don't like the name "-Xclang-driver" as a prefix for an option
to the g++-compatible driver.

[rnk]

> I'd like there to be a cl.exe compatible clang driver. I think the best
way
> for this to work is to have the existing clang driver detect when it's
being
> invoked as cl.exe, similar to how clang++ vs. clang works today. For
> testing, there should be a -ccc-msvc option which turns on the same
> behavior.
>
> Some relevant past discussion on this topic:
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html
>
> The priorities for the driver should be, in order:
>
> 1. Drop in compatibility with MSVC
> 2. Compatibility with the existing clang driver
> 3. Don't change the meaning of existing gcc-style driver command lines
(an
> argument with a / prefix is an input path, not an option)
> 4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options as
> much as possible
>
> I think #2 is important so that cross-platform projects (like LLVM) won't
> have to spell clang options like -fcolor-diagnostics or
-Wc++11-extensions
> twice.

Hmm, would cross-platform projects use the cl.exe-compatible driver?

Yes. Consider the use case of generating a Visual Studio project file that
uses clang for diagnostics and or codegen, and wanting to control those
diagnostics.

> It's important to know that there are a few conflicts with MSVC like -MD,
> -MT, and things like -Zi where clang accepts -Z as a joined option, so
there
> needs to be a good solution for disambiguating them.
>
> Previously people have discussed using the slash prefix to disambiguate
> between the MSVC and clang meanings, but since cl.exe accepts both - and
/
> prefixes for all of its options, I don't like this approach. There are
> probably many Unix expats out there on Windows consistently using
dash-style
> option prefixes everywhere, like me.
>
> I think clang should give a higher precedence to all MSVC options before
> falling back to gcc style options. To resolve conflicts, there will
have to
> be an escape flag. I propose -Xclang-driver, which is similar to
-Xclang,
> except that it gets interpreted by the driver. Hopefully Microsoft never
> adds an -Xclang-driver flag.

It sounds like your mental model is that we have a "Clang driver", and
a set of extensions for a "cl.exe-compatible driver". I think it might
be a better perspective to think about this as a "g++-compatible
driver" and a "cl.exe-compatible driver". I guess what I'm saying is
that I don't like the name "-Xclang-driver" as a prefix for an option
to the g++-compatible driver.

Would you prefer -Xgcc-driver? I can see how -Xclang-driver would become
confusing, since they are both clang. Maybe -Xdriver? Honestly I don't
expect anyone will use the escape, but I wanted to propose it for
completeness and forwards compatibility if Microsoft adds a more severe
conflict for something core like -o.

[zygoloid]

> I'd like there to be a cl.exe compatible clang driver. I think the best
> way
> for this to work is to have the existing clang driver detect when it's
> being
> invoked as cl.exe, similar to how clang++ vs. clang works today. For
> testing, there should be a -ccc-msvc option which turns on the same
> behavior.
>
> Some relevant past discussion on this topic:
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html
>
> The priorities for the driver should be, in order:
>
> 1. Drop in compatibility with MSVC
> 2. Compatibility with the existing clang driver
> 3. Don't change the meaning of existing gcc-style driver command lines
> (an
> argument with a / prefix is an input path, not an option)
> 4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options
> as
> much as possible
>
> I think #2 is important so that cross-platform projects (like LLVM)
> won't
> have to spell clang options like -fcolor-diagnostics or
> -Wc++11-extensions
> twice.

Hmm, would cross-platform projects use the cl.exe-compatible driver?

Yes. Consider the use case of generating a Visual Studio project file that
uses clang for diagnostics and or codegen, and wanting to control those
diagnostics.

It seems like it should be possible to teach the build system to add
the -Xwhatever in this case. Depending on how many conflicting options
we have, cross-platform code may not be able to get away with using
g++ driver options for the cl.exe driver anyway.

Maybe we should have some begin/end markers for g++ driver arguments
so we don't have to add -Xwhatever before each one.

> It's important to know that there are a few conflicts with MSVC like
> -MD,
> -MT, and things like -Zi where clang accepts -Z as a joined option, so
> there
> needs to be a good solution for disambiguating them.
>
> Previously people have discussed using the slash prefix to disambiguate
> between the MSVC and clang meanings, but since cl.exe accepts both - and
> /
> prefixes for all of its options, I don't like this approach. There are
> probably many Unix expats out there on Windows consistently using
> dash-style
> option prefixes everywhere, like me.
>
> I think clang should give a higher precedence to all MSVC options before
> falling back to gcc style options. To resolve conflicts, there will
> have to
> be an escape flag. I propose -Xclang-driver, which is similar to
> -Xclang,
> except that it gets interpreted by the driver. Hopefully Microsoft
> never
> adds an -Xclang-driver flag.

It sounds like your mental model is that we have a "Clang driver", and
a set of extensions for a "cl.exe-compatible driver". I think it might
be a better perspective to think about this as a "g++-compatible
driver" and a "cl.exe-compatible driver". I guess what I'm saying is
that I don't like the name "-Xclang-driver" as a prefix for an option
to the g++-compatible driver.

Would you prefer -Xgcc-driver? I can see how -Xclang-driver would become
confusing, since they are both clang. Maybe -Xdriver? Honestly I don't
expect anyone will use the escape, but I wanted to propose it for
completeness and forwards compatibility if Microsoft adds a more severe
conflict for something core like -o.

They're both drivers, too, so -Xdriver doesn't seem quite right.
Thoughts on -Xgcc for this case, and -Xcl.exe for the opposite case? I
have reservations about this, since -Xfoo is currently used to mean
"use these options when running the foo subprocess", but equally we
can interpret it as meaning "here's an option in foo's option syntax".

[rnk]

>>
>> > I'd like there to be a cl.exe compatible clang driver. I think the
best
>> > way
>> > for this to work is to have the existing clang driver detect when it's
>> > being
>> > invoked as cl.exe, similar to how clang++ vs. clang works today. For
>> > testing, there should be a -ccc-msvc option which turns on the same
>> > behavior.
>> >
>> > Some relevant past discussion on this topic:
>> > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html
>> >
>> > The priorities for the driver should be, in order:
>> >
>> > 1. Drop in compatibility with MSVC
>> > 2. Compatibility with the existing clang driver
>> > 3. Don't change the meaning of existing gcc-style driver command lines
>> > (an
>> > argument with a / prefix is an input path, not an option)
>> > 4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options
>> > as
>> > much as possible
>> >
>> > I think #2 is important so that cross-platform projects (like LLVM)
>> > won't
>> > have to spell clang options like -fcolor-diagnostics or
>> > -Wc++11-extensions
>> > twice.
>>
>> Hmm, would cross-platform projects use the cl.exe-compatible driver?
>
>
> Yes. Consider the use case of generating a Visual Studio project file
that
> uses clang for diagnostics and or codegen, and wanting to control those
> diagnostics.

It seems like it should be possible to teach the build system to add
the -Xwhatever in this case. Depending on how many conflicting options
we have, cross-platform code may not be able to get away with using
g++ driver options for the cl.exe driver anyway.

What I have in mind right now is CMake, where every user pretty much does
their own ad hoc flag checking and munging. Every CMake user would have to
say add_cflag_if_supported("-fblah") / add_cflag_if_supported("-Xescape
-fblah"), or it would be in some 'if clang' block.

One thing we could do to cut complexity here is forget about supporting the
long tail of gcc driver options and just focus on a short-list of groups
like -W, -f, -m, and maybe others.

Maybe we should have some begin/end markers for g++ driver arguments

so we don't have to add -Xwhatever before each one.

I could see begin and end markers working, but I don't like the
statefulness that they add to the flags. It's already hard to read ld's
--start-group --end-group flags.

>> > It's important to know that there are a few conflicts with MSVC like
>> > -MD,
>> > -MT, and things like -Zi where clang accepts -Z as a joined option, so
>> > there
>> > needs to be a good solution for disambiguating them.
>> >
>> > Previously people have discussed using the slash prefix to
disambiguate
>> > between the MSVC and clang meanings, but since cl.exe accepts both -
and
>> > /
>> > prefixes for all of its options, I don't like this approach. There
are
>> > probably many Unix expats out there on Windows consistently using
>> > dash-style
>> > option prefixes everywhere, like me.
>> >
>> > I think clang should give a higher precedence to all MSVC options
before
>> > falling back to gcc style options. To resolve conflicts, there will
>> > have to
>> > be an escape flag. I propose -Xclang-driver, which is similar to
>> > -Xclang,
>> > except that it gets interpreted by the driver. Hopefully Microsoft
>> > never
>> > adds an -Xclang-driver flag.
>>
>> It sounds like your mental model is that we have a "Clang driver", and
>> a set of extensions for a "cl.exe-compatible driver". I think it might
>> be a better perspective to think about this as a "g++-compatible
>> driver" and a "cl.exe-compatible driver". I guess what I'm saying is
>> that I don't like the name "-Xclang-driver" as a prefix for an option
>> to the g++-compatible driver.
>
>
> Would you prefer -Xgcc-driver? I can see how -Xclang-driver would become
> confusing, since they are both clang. Maybe -Xdriver? Honestly I don't
> expect anyone will use the escape, but I wanted to propose it for
> completeness and forwards compatibility if Microsoft adds a more severe
> conflict for something core like -o.

They're both drivers, too, so -Xdriver doesn't seem quite right.
Thoughts on -Xgcc for this case, and -Xcl.exe for the opposite case? I
have reservations about this, since -Xfoo is currently used to mean
"use these options when running the foo subprocess", but equally we
can interpret it as meaning "here's an option in foo's option syntax".

-Xgcc doesn't seem right since we invoke do invoke gcc to do things like
assemble for mingw. How about something terribly explicit like
--escaped-clang-args="multiple args here"?

[zygoloid]

>>
>> > I'd like there to be a cl.exe compatible clang driver. I think the
>> > best
>> > way
>> > for this to work is to have the existing clang driver detect when
>> > it's
>> > being
>> > invoked as cl.exe, similar to how clang++ vs. clang works today. For
>> > testing, there should be a -ccc-msvc option which turns on the same
>> > behavior.
>> >
>> > Some relevant past discussion on this topic:
>> > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html
>> >
>> > The priorities for the driver should be, in order:
>> >
>> > 1. Drop in compatibility with MSVC
>> > 2. Compatibility with the existing clang driver
>> > 3. Don't change the meaning of existing gcc-style driver command
>> > lines
>> > (an
>> > argument with a / prefix is an input path, not an option)
>> > 4. Avoid -cc1 option explosion by aliasing MSVC options to gcc
>> > options
>> > as
>> > much as possible
>> >
>> > I think #2 is important so that cross-platform projects (like LLVM)
>> > won't
>> > have to spell clang options like -fcolor-diagnostics or
>> > -Wc++11-extensions
>> > twice.
>>
>> Hmm, would cross-platform projects use the cl.exe-compatible driver?
>
>
> Yes. Consider the use case of generating a Visual Studio project file
> that
> uses clang for diagnostics and or codegen, and wanting to control those
> diagnostics.

It seems like it should be possible to teach the build system to add
the -Xwhatever in this case. Depending on how many conflicting options
we have, cross-platform code may not be able to get away with using
g++ driver options for the cl.exe driver anyway.

What I have in mind right now is CMake, where every user pretty much does
their own ad hoc flag checking and munging. Every CMake user would have to
say add_cflag_if_supported("-fblah") / add_cflag_if_supported("-Xescape
-fblah"), or it would be in some 'if clang' block.

It needs to be in an "if clang" block regardless if these are
clang-specific flags. And they need the -Xwhatever regardless if the
flag means something else to cl.exe. Also, I don't see any problem
with supporting -Xwhatever from both drivers, so you don't even need
special case code for the cl.exe case. Just do:

if(clang)
    add_cflag_if_supported("-Xwhatever -fblah")
endif(clang)

One thing we could do to cut complexity here is forget about supporting the
long tail of gcc driver options and just focus on a short-list of groups
like -W, -f, -m, and maybe others.

I think it makes sense to figure out which of the g++ driver switches
we want to support for the cl.exe driver, and what the best way of
exposing them to that driver would be. Which of the -W, -f, -m, ...
namespaces which we use heavily are already occupied by cl.exe
options? Does cl.exe have naming conventions for language flags and
code generation flags? What's the syntax for enabling or disabling
individual warnings? Does it have any double-dash options?

Maybe we should have some begin/end markers for g++ driver arguments
so we don't have to add -Xwhatever before each one.

I could see begin and end markers working, but I don't like the statefulness
that they add to the flags. It's already hard to read ld's --start-group
--end-group flags.

>> > It's important to know that there are a few conflicts with MSVC like
>> > -MD,
>> > -MT, and things like -Zi where clang accepts -Z as a joined option,
>> > so
>> > there
>> > needs to be a good solution for disambiguating them.
>> >
>> > Previously people have discussed using the slash prefix to
>> > disambiguate
>> > between the MSVC and clang meanings, but since cl.exe accepts both -
>> > and
>> > /
>> > prefixes for all of its options, I don't like this approach. There
>> > are
>> > probably many Unix expats out there on Windows consistently using
>> > dash-style
>> > option prefixes everywhere, like me.
>> >
>> > I think clang should give a higher precedence to all MSVC options
>> > before
>> > falling back to gcc style options. To resolve conflicts, there will
>> > have to
>> > be an escape flag. I propose -Xclang-driver, which is similar to
>> > -Xclang,
>> > except that it gets interpreted by the driver. Hopefully Microsoft
>> > never
>> > adds an -Xclang-driver flag.
>>
>> It sounds like your mental model is that we have a "Clang driver", and
>> a set of extensions for a "cl.exe-compatible driver". I think it might
>> be a better perspective to think about this as a "g++-compatible
>> driver" and a "cl.exe-compatible driver". I guess what I'm saying is
>> that I don't like the name "-Xclang-driver" as a prefix for an option
>> to the g++-compatible driver.
>
>
> Would you prefer -Xgcc-driver? I can see how -Xclang-driver would
> become
> confusing, since they are both clang. Maybe -Xdriver? Honestly I don't
> expect anyone will use the escape, but I wanted to propose it for
> completeness and forwards compatibility if Microsoft adds a more severe
> conflict for something core like -o.

They're both drivers, too, so -Xdriver doesn't seem quite right.
Thoughts on -Xgcc for this case, and -Xcl.exe for the opposite case? I
have reservations about this, since -Xfoo is currently used to mean
"use these options when running the foo subprocess", but equally we
can interpret it as meaning "here's an option in foo's option syntax".

-Xgcc doesn't seem right since we invoke do invoke gcc to do things like
assemble for mingw.

Fair point. -Xgcc-driver as you previously suggested, or
-Xclang-gcc-driver, or similar, then?

How about something terribly explicit like
--escaped-clang-args="multiple args here"?

Personally, I'd prefer for us to stay out of the game of splitting
arguments on spaces. But I guess it's a Windowsy thing for programs to
do.

"clang" there isn't really right, and double-dash seems like it might
not fit in very well with the cl.exe style of command line arguments.

[Chandler_Carruth]

This thread’s chain of emails is somewhat tricky to reply to so I’ll just start fresh… Sorry for that…

I think we need to admit that there is some preferred Clang set of options and option syntaxes. They may be chosen to be consistent with GCC in some ways, but they’re not actually compatible. The most frequently cited here is actually a case in point: GCC doesn’t support -fcolor-diagnostics, so I don’t think we can sensibly call it ‘-Xgcc-driver=-fcolor-diagnostics’.

But let’s simplify this: we really don’t need to support all of the existing command line syntax when operating in a cl.exe compatible mode. Instead, let’s focus on what the important use cases are for user provided flags that might be useful to support across platforms:

• High level driver flags like ‘–coverage’, ‘–target’, … I think these are OK as I don’t think MS supports double-dash syntax, or if they do I doubt many use it.

• Warnings using the ‘-Wsome-long-name’ syntax: are there any conflicts here?

• Language features using the ‘-fsome-long-name’ syntax: are there any conflicts here?

• Machine features using the ‘-msome-long-name’ syntax: are there any conflicts here?

• Debugging features using the ‘-gsome-long-name’ syntax? Not sure we even want this, but maybe: are there any conflicts here?

If we can make these work, I think we should stop. I think we should actually whitelist the set of flags that are supported in cl.exe mode so we find out if people want specific flags rather than things behaving weirdly.

If there are conflicts above, we could even consider renaming the clang flags to something that wouldn’t conflict, but let’s see if it’s even a problem.

I do think there will be weird cases where users want to pass a very specific Clang flag that isn’t in this set, but I think it’s going to be very weird and I’m not worried about them having some hoops to jump through to get to it. So if we have to test for the flag in N different ways, or not, whatever. I’m OK with that.

I see three common things that we could use to make up the name for this: GCC-like syntactical conventions, Unix-like platform default mode, and the fact that Clang developers tend to view it is the primary Clang interface to the point that much of this commandline interface is shared between the driver and CC1. Using these I would come up with:

–gcc-style-flag=…
–unix-style-flag=…
–core-flag=…

I find the third one least bad. I find the GCC one confusing because I think it will be confused with when we are actually trying to be compatible with GCC…

I find using either ‘–’ or ‘-X’ as a prefix fine, I’m not too fussed about the subprocess traditional role of -X but I don’t care much.

[rnk]

I don't think that's standard practice for existing CMake and autoconf
build systems. I've met many people who believe in feature testing
compiler flags with a test compile, rather than maintaining a list of
compiler vendors and versions that support a given flag. Personally, I've
always hated this because it's really expensive and wastes a lot of time.

The other school of thought is to do the obvious thing and say "if gcc, add
-fno-rtti, if msvc, add /GR-", and then change it when you need to build
with clang.

I also don't want to ask people to escape gcc style flags everywhere.
Consider -Wextra, which gcc and clang accept, and today might be written
as 'add_if_supported(-Wextra)' or 'if (gcc_compatible) add(-Wextra)'.

It seems best to have that work for all of gcc, clang, and clang-cl,
without adding code to add on -Xescape for clang.

[rnk]

This thread's chain of emails is somewhat tricky to reply to so I'll just
start fresh... Sorry for that...

I think we need to admit that there is some preferred Clang set of options
and option syntaxes. They may be chosen to be consistent with GCC in some
ways, but they're not actually compatible. The most frequently cited here
is actually a case in point: GCC doesn't support -fcolor-diagnostics, so I
don't think we can sensibly call it '-Xgcc-driver=-fcolor-diagnostics'.

But let's simplify this: we really don't need to support *all* of the
existing command line syntax when operating in a cl.exe compatible mode.
Instead, let's focus on what the important use cases are for user provided
flags that might be useful to support across platforms:

- High level driver flags like '--coverage', '--target', .... I think
these are OK as I don't think MS supports double-dash syntax, or if they do
I doubt many use it.

Yep, there are no double-dash flags, or at least I can't find them.

- Warnings using the '-Wsome-long-name' syntax: are there any conflicts
here?

- Language features using the '-fsome-long-name' syntax: are there any
conflicts here?

- Machine features using the '-msome-long-name' syntax: are there any
conflicts here?

- Debugging features using the '-gsome-long-name' syntax? Not sure we even
want this, but maybe: are there any conflicts here?

Basically cl.exe has very few long option names, so none of those prefixes
conflict today. -Wall exists, but it means something more like -Wpedantic.
Not a big deal.

If we can make these work, I think we should stop. I think we should

actually whitelist the set of flags that are supported in cl.exe mode so we
find out if people want specific flags rather than things behaving weirdly.

If there are conflicts above, we could even consider renaming the clang
flags to something that wouldn't conflict, but let's see if it's even a
problem.

I do think there will be weird cases where users want to pass a very
specific Clang flag that isn't in this set, but I think it's going to be
*very* weird and I'm not worried about them having some hoops to jump
through to get to it. So if we have to test for the flag in N different
ways, or not, whatever. I'm OK with that.

I see three common things that we could use to make up the name for this:
GCC-like syntactical conventions, Unix-like platform default mode, and the
fact that Clang developers tend to view it is the primary Clang interface
to the point that much of this commandline interface is shared between the
driver and CC1. Using these I would come up with:

--gcc-style-flag=...
--unix-style-flag=...
--core-flag=...

I find the third one least bad. I find the GCC one confusing because I
think it will be confused with when we are actually trying to be compatible
with GCC...

I think a double-dash prefix is best for the escape because there are no
double-dash cl.exe options. I like --core-flag= the best from the set
above, although it seems to mean cc1 option at first glance, when it really
isn't.

[dblaikie]

>>
>> > I'd like there to be a cl.exe compatible clang driver. I think the
>> > best
>> > way
>> > for this to work is to have the existing clang driver detect when
>> > it's
>> > being
>> > invoked as cl.exe, similar to how clang++ vs. clang works today. For
>> > testing, there should be a -ccc-msvc option which turns on the same
>> > behavior.
>> >
>> > Some relevant past discussion on this topic:
>> > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html
>> >
>> > The priorities for the driver should be, in order:
>> >
>> > 1. Drop in compatibility with MSVC
>> > 2. Compatibility with the existing clang driver
>> > 3. Don't change the meaning of existing gcc-style driver command
>> > lines
>> > (an
>> > argument with a / prefix is an input path, not an option)
>> > 4. Avoid -cc1 option explosion by aliasing MSVC options to gcc
>> > options
>> > as
>> > much as possible
>> >
>> > I think #2 is important so that cross-platform projects (like LLVM)
>> > won't
>> > have to spell clang options like -fcolor-diagnostics or
>> > -Wc++11-extensions
>> > twice.
>>
>> Hmm, would cross-platform projects use the cl.exe-compatible driver?
>
>
> Yes. Consider the use case of generating a Visual Studio project file
> that
> uses clang for diagnostics and or codegen, and wanting to control those
> diagnostics.

It seems like it should be possible to teach the build system to add
the -Xwhatever in this case. Depending on how many conflicting options
we have, cross-platform code may not be able to get away with using
g++ driver options for the cl.exe driver anyway.

What I have in mind right now is CMake, where every user pretty much does
their own ad hoc flag checking and munging. Every CMake user would have to
say add_cflag_if_supported("-fblah") / add_cflag_if_supported("-Xescape
-fblah"), or it would be in some 'if clang' block.

Yeah, I'm still not really understanding which clients we would be
targeting by having this hybrid driver that would accept both CL and
GCC arguments.

Presumably someone with a build system that already targets GCC would
use the existing GCC-compatible Clang driver, right? Why would they
have a need for a hybrid?

(& equally, anyone with an existing CL-compatible build system would
use the CL-compatible version, why would they have a need for
GCC-style arguments? (OK, I suppose so they could enable/disable Clang
features that aren't exposed in the CL-compatible interface
explicitly?))

[Chandler_Carruth]

Exactly. When we add new flags, we avoid the need to find a MS-compatible
spelling. Also, it makes it slightly easier for cross-platform open source
projects to opt into a Clang flag.

I dunno if these are "important" reasons, but they at least seem plausible
to me.

[rnk]

[Summarizing some offline discussion for the list]

Maybe the way forward is something like this. First, underlying all the argv[0] name heuristics is a switch like --driver-flavor=gcc / --driver-flavor=cl and maybe g++.

We add two more flags to the option table: GCCOption and ClangOption. When in gcc driver mode, only clang and gcc options are accepted. For example, -fcolor-diagnostics is our preferred spelling of that option, so it gets the clang flag, and -fdiagnostics-color gets the gcc flag. When using the cl driver flavor, we accept cl args and clang args.

We should only put the ClangOption flag on options whose spellings don’t conflict with cl.exe and that fall into the buckets Chandler mentioned: high-level double dash, or non-conflicting single character group prefix.

GCCOption goes on everything that gcc accepts. This is actually handy because there are users who do things like run clang -fsyntax-only and then invoke gcc for codegen, and they need to know the subset of flags that gcc supports.

One open question is, is it even worth creating an escape to allow users of clang-cl to get at the gcc options, or do we tell them not to do that, or use the private -cc1 options as a hacky workaround?

Similarly, we expect we’ll want to be able to invoke cl.exe from clang-cl if someone asks for an unimplemented feature like /clr:pure.

[Chandler_Carruth]

The nice thing is that if we don't create the escape now and find out we
need it, we can always add it later. Let's see how far we get without it?

[kimgr]

Hi Reid, Hans,

I'd like there to be a cl.exe compatible clang driver. I think the best way
for this to work is to have the existing clang driver detect when it's being
invoked as cl.exe, similar to how clang++ vs. clang works today. For
testing, there should be a -ccc-msvc option which turns on the same
behavior [...]

I don't understand the exact responsibilities of the driver and its
different modes, but would the presence of a cl.exe-compatible
driver/mode allow Clang tools to accept cl.exe command-lines?

I'm curious, because it should be pretty easy to build a
compile_commands.json from Visual Studio project files, and that in
turn would enable tools to run on MSVC-ish code with or without CMake.

Thanks,
- Kim

[Chandler_Carruth]

Hi Reid, Hans,

> I'd like there to be a cl.exe compatible clang driver. I think the best
way
> for this to work is to have the existing clang driver detect when it's
being
> invoked as cl.exe, similar to how clang++ vs. clang works today. For
> testing, there should be a -ccc-msvc option which turns on the same
> behavior [...]

I don't understand the exact responsibilities of the driver and its
different modes, but would the presence of a cl.exe-compatible
driver/mode allow Clang tools to accept cl.exe command-lines?

Absolutely. Note that there is probably some work to do on the tooling
layer to get all of this to work -- we haven't tested it that I know -- so
it might be something that would be good to play with and post patches if
you hit issues.

I'm curious, because it should be pretty easy to build a
compile_commands.json from Visual Studio project files, and that in
turn would enable tools to run on MSVC-ish code with or without CMake.

This would be *wonderful*. Especially if it could be effectively integrated
with visual studio itself so that it is updated nicely.

[kimgr]

Thanks, Chandler!

Absolutely. Note that there is probably some work to do on the tooling layer
to get all of this to work -- we haven't tested it that I know -- so it
might be something that would be good to play with and post patches if you
hit issues.

I help maintain IWYU, and we're not yet using the tooling library, but
this sounds like a really good reason to start doing so. I'll see
whether we can get that far before the cl driver stuff settles.

I'm curious, because it should be pretty easy to build a
compile_commands.json from Visual Studio project files, and that in
turn would enable tools to run on MSVC-ish code with or without CMake.

This would be *wonderful*. Especially if it could be effectively integrated
with visual studio itself so that it is updated nicely.

Yeah, it sounds like it would open the world of Clang tools to a lot
more build systems!

- Kim