fix: Don't bail when a linker plugin doesn't claim an IR archive member - #2027

Adding a regression test for this is a bit tricky because we need to use different compilers (clang and gcc) for archive and other builds 🤔
While it's possible to commit an object file compiled with gcc, this would be somewhat hacky. A more ideal approach would be to extend test directives to support entries like //#Archive:unclaimed.c:gcc:-flto -fno-fat-lto-objects. However, implementing this should extend support to other similar directives rather than just limiting it to Archive, suggesting it would require significant refactoring.

Does it work to use gcc as the linker driver, clang as the compiler, then specify -flto only for the one archive?

Does it work to use gcc as the linker driver, clang as the compiler, then specify -flto only for the one archive?

Ah right. There was a simple solution.

Does this mean that now we'll now, in general, report an undefined symbol error instead of reporting that the archive contains the wrong kind of IR?

While this isn't true in general (it's limited to the archive case), yes. I think users naturally expect an "undefined symbol" error if a symbol was meant to be provided via an archive but the IR member wasn't claimed by the plugin.

I think users naturally expect an "undefined symbol" error if a symbol was meant to be provided via an archive but the IR member wasn't claimed by the plugin.

I'm not sure what users expect, but an error telling them that they're trying to link LLVM IR using the GCC plugin would almost certainly be more useful than an undefined symbol error. We have tests for that, but I guess the tests only cover the case of an object, not an archive. I just tried adding the following test:

//#Config:clang-link-gcc-archive:error
//#Compiler:clang
//#CompArgs:-flto
//#LinkerDriver:gcc
//#SkipLinker:ld
//#LinkArgs:-Wl,-znow -flto -nostdlib
//#Object:runtime.c
//#Archive:linker-plugin-lto-2.c
//#ExpectError:(contains LLVM-IR, but the linker plugin|Wild was compiled without linker-plugin support)

Strangely it passes even with your PR. Perhaps you'd like to add it to your PR to ensure we don't regress that case. Although I'd be interested to learn why it passes.

I'd be interested to learn why it passes

I think it's because //#CompArgs:-flto makes runtime.c an LLVM IR input as well. Direct (non-archive) IR files still produce the "... contains LLVM IR, but the linker plugin ..." error, so the test ends up passing.

I'm not sure what users expect, but an error telling them that they're trying to link LLVM IR using the GCC plugin would almost certainly be more useful than an undefined symbol error.

I generally (edit: I mean the general case other than archives) agree, but in the case of archives, the situation differs because archived components may contain members with different IR that aren't referenced. In fact, GNU ld and lld exhibit the same behavior (they pass the mold tests that no longer need to be skipped in this PR).