See e.g., http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/21470/consoleFull#19036563798254eaf0-7326-4999-85b0-388101f2d404 This test was (re-)introduced in: [clang-tools-extra] r280839 - Resubmit "Add a test for clang-tidy using the clang-cl driver." Looks like the path is interpreted as a '/U' option in clang-cl mode: clang-check "/Volumes/.../clang-cl-driver.cpp" -- --driver-mode=cl -### clang-check "/Users/.../clang-cl-driver.cpp" -- --driver-mode=cl -### The latter emits an error: warning: argument unused during compilation: '-U sers/.../clang-cl-driver.cpp' error: unable to handle compilation, expected exactly one compiler job in '' Error while processing /Users/.../clang-cl-driver.cpp.
Reverted in r280975. I'll take a look later today; ideas welcome.
I haven't found a good way to avoid this problem. It exists even for the clang driver: there's no way to compile a file called, say, '-Df.c'. '--' fools the driver, but I don't think there's a way to fool -cc1. So, Zachary, unless you have another idea, I'd suggest only enabling the test on Windows, where it's known to be safe?
Reid, do you have any ideas here? TL;DR - Running clang in cl mode on platforms that use a / separator in paths interprets some paths as command line options.
Isn't this known? We have comments in all our driver tests about it...
// Note: %s must be preceded by --, otherwise it may be interpreted as a // command-line option, e.g. on Mac where %s is commonly under /Users.
Looks like this patch never relanded.
This never relanded, but I don't think there's anything to do here.