[clang][driver] -S and -c are incompatible after #101103 when using Werror, even without -fsyntax-only

[ilovepi]

After #101103, -S and -c options seem to be incompatible when using -Werror. This doesn't seem to be intentional, from what I can tell.

The following comands result in clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]

touch foo.c
~/llvm-project/build/bin/clang -S -O0 -Werror  -c .foo.c -o foo.c.o

CC: @MaskRay

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Paul Kirth (ilovepi)

After https://github.com//pull/101103, `-S` and `-c` options seem to be incompatible when using -Werror. This doesn't seem to be intentional, from what I can tell.

The following program results in clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]

touch foo.c
~/llvm-project/build/bin/clang -S -O0 -Werror  -c .foo.c -o foo.c.o

CC: @MaskRay

[MaskRay]

The warning works as intended.

touch foo.c
~/llvm-project/build/bin/clang -S -O0 -Werror  -c .foo.c -o foo.c.o

If you pick any two from the action options (-fsyntax-only -S -E -c etc), there should be a warning.

[s-barannikov]

I found the old overriding behavior quite useful. For example, I could copy & paste a command from a log, add -E at the end, and get preprocessed output to start preparing a reproducer. Now I will have to locate the "-c" and / or "-Werror" somewhere in 2k characters line and erase it first. This is very inconvenient.
I used to use -S the same way, i.e. copy a command from a log, append -S and get an assembly file instead of an object file.

What was wrong with the old behavior? Why did it have to be changed?

[MaskRay]

We had many -Wunused-command-line-argument for the action options and we also had lots of inconsistency. E.g. -fsyntax-only -M, -S -E -c, and -E -fsyntax-only all report warnings for a long time while some combinations did not. #98607 improved some consistency (the commit message wasn't accurate. It's difficult to enumerate all behavior changing scenarios).

If there is a long command with -Werror, you could add -E -w instead.

[s-barannikov]

Well, consistency is good, I won't argue with that.
Unfortunately, it is consistent the other way :) Usually options from the same group override each other, but in this case the first option seems to win and the rest are ignored. I'd like it to be the opposite (as it was before): the last option wins and the rest are ignored (with or without warnings, not a big difference).

If there is a long command with -Werror, you could add -E -w instead.

I'd have to insert -E before -c. It looks like I can't add it at the end because it will be ignored. That's my main concern. -Werror is just another (weaker) argument.

I guess this is not the issue where I should complain, so I'm stopping :)

PS
(I hope that at least '-o' option won't suffer the same fate, I often append it at the end to override the previous destination.)

[MaskRay]

The overriding usually happens with -ffoo -fno-foo.
For options of different stem names, there are many different behaviors, and these action options might be weird...

I'd have to insert -E before -c. It looks like I can't add it at the end because it will be ignored. That's my main concern. -Werror is just another (weaker) argument.

You don't:) -E takes precedence.

• -S -c == -c -S == -S
• -S -fsyntax-only == -fsyntax-only -S == -fsyntax-only
• -E -fsyntax-only == -fsyntax-only -E == -E

The precedence order is from GCC. We try to respect that while having our own opinion (warning, -Wunused-command-line-argument, which GCC doesn't have).
On the other side, the -Wunused-command-line-argument diagnostic could give the user a hint what is going on...

[s-barannikov]

Ahh, all good then, sorry for the noise!