[PATCH] D49189: Omit path to lld binary from lld's error and warning diagnostics.

Rui Ueyama via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 11 13:06:07 PDT 2018


ruiu added a comment.

In https://reviews.llvm.org/D49189#1159054, @thakis wrote:

> Thanks for taking a look!
>
> > I think we should at least include "ld.lld: " part in the error message, because without that, it is sometimes hard to identify what command is emitting an error in a long build log.
>
> In what cases? clang doesn't prepend its errors with "clang:" (except for driver-level diags) either. For failed build steps, most build tools output the failing build step above the error so it's clear from context where the error comes from.
>
> I see how this is is useful in the abstract, but I can't think of concrete examples (it's well possible I'm just lacking imagination), so I thought not printing anything is the best approach: If there's some concrete case where it helps, we'll learn about it and can add something back, and if there isn't then we end up with easier to read output.  If we include some prefix and it's not needed, we'll always be stuck with it.


If you invoke the linker directly, you can just search for the linker name in a log and find an error, but if you do that through the compiler driver, is it easy to determine whether it's a link error or not, I guess. I don't a good example in hand, but the first thing I usually do to search for a link error is to search for "lld" after Ctrl-F. It's handy.

As to not printing out anything, I believe clang's behavior is somewhat unusual, as most command usually includes argv[0] in their error messages. It feels like we probably should follow the usual convention than clang.

Maybe printing out the basename of argv[0] could get the right balance. What do you think?


https://reviews.llvm.org/D49189





More information about the llvm-commits mailing list