[all-commits] [llvm/llvm-project] 648fea: [clang] Make the driver not diagnose errors on non...

[Nico Weber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 648feabc65d8ec20e5d39ac88e019d310955a6e6
      https://github.com/llvm/llvm-project/commit/648feabc65d8ec20e5d39ac88e019d310955a6e6
  Author: Nico Weber <thakis at chromium.org>
  Date:   2021-09-13 (Mon, 13 Sep 2021)

  Changed paths:
    M clang/lib/Driver/Driver.cpp
    M clang/test/Driver/cl-inputs.c
    M clang/test/Driver/cl-link.c
    M clang/test/Driver/unknown-arg.c
    M flang/test/Driver/missing-input.f90

  Log Message:
  -----------
  [clang] Make the driver not diagnose errors on nonexistent linker inputs

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