When nonexistent linker inputs are passed to the driver, the linker now errors out, instead of the compiler. If the linker does not run, clang now emits a "warning: linker input unused" instead of an error for nonexistent files. The motivation for this change is that I noticed that `clang-cl /winsysroot sysroot main.cc ole32.lib` emitted a "ole32.lib not found" error, even though the linker finds it just fine when I run `clang-cl /winsysroot sysroot main.cc /link ole32.lib`. The same problem occurs if running `clang-cl main.cc ole32.lib` in a non-MSVC shell. The problem is that DiagnoseInputExistence() only looked for libs in %LIB%, but MSVCToolChain uses much more involved techniques. For this particular problem, we could make DiagnoseInputExistence() ask the toolchain to see if it can find a .lib file, but in general the driver can't know what the linker will do to find files, so it shouldn't try. For example, if we implement PR24616, lld-link will look in the registry to determine a good default for %LIB% if it isn't set. This is less or a problem for the gcc driver, since .a paths there are either passed via -l flags (which honor -L), or via a qualified path (that doesn't honor -L) -- but for example ld.lld's --chroot flag can also trigger this problem. Without this patch, `clang -fuse-ld=lld -Wl,--chroot,some/dir /file.o` will complain that `/file.o` doesn't exist, even though `clang -fuse-ld=lld -Wl,--chroot,some/dir -Wl,/file.o` succeeds just fine. This implements rnk's suggestion on the old bug PR27234. Differential Revision: https://reviews.llvm.org/D109624
1.3 KiB
1.3 KiB