[lld] Add version info to generic driver output

[keith]

Summary

This makes it easier to see version info without having to use a
specific shim. Example:

lld is a generic driver. (LLD 15.0.0)
Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead

[keith]

Improve formatting

[MaskRay]

The purpose is unclear to me about why we need to overload here with more information.
If the user wants to get the version, they can run lld -flavor gnu --version, or using another flavor.

[keith]

This is purely a convenience addition so users don't have to know about -flavor gnu, or specify one of the other shims

[MaskRay]

Such use cases can't be common, can they?
We'd also discourage lld without -flavor usage. This may lure users into using it.
In addition, error messages in lld don't append the version information. Special casing this diagnostic will introduce inconsistency.

[keith]

I doubt they're super common, but I figured the complexity of adding this was so low that it made sense to. In my case I was trying to compare versions of the installed lld on linux systems at /usr/bin/lld, so I found myself trying to do /usr/bin/ld --version and then /usr/bin/lld --version, where the latter didn't print the version. I don't think we have to worry about more folks calling this since the utility of calling it is still very small, and the output is clear that the other shims should be called.

[MaskRay]

I agree that it's uncommon, so I try to evaluate it from some aspects like code complexity, consistency, and feature orthogonality.
I believe it fails for all the 3 aspects. It does improve the convenience, but you said, is uncommon. Therefore I do not see this change justifying.

[kastiglione]

@MaskRay sorry for butting in, but what am I missing here? The hardline and opaque rejection don't reconcile with such a minor change. To me, there is no complexity whatsoever to this change. You mention consistency, but don't say with what (which doesn't allow people to make their own judgement). I also don't see how feature orthogonality relates. Rejections happen, but I think it's rejections ought to be clear to readers, and in this instance I found it confusing.

[MaskRay]

In D122924#3431303, @kastiglione wrote:

@MaskRay sorry for butting in, but what am I missing here? The hardline and opaque rejection don't reconcile with such a minor change. To me, there is no complexity whatsoever to this change. You mention consistency, but don't say with what (which doesn't allow people to make their own judgement). I also don't see how feature orthogonality relates. Rejections happen, but I think it's rejections ought to be clear to readers, and in this instance I found it confusing.

consistency: this is a fatal error. for other fatal errors we don't report the version.
i implied this in "In addition, error messages in lld don't append the version information." in a previous comment.

orthogonality: this is implied as well. lld -flavor gnu --version reports the version.

complexity: both #include "lld/Common/Version.h" and the function call is extra complexity.

[kastiglione]

I don't agree that an #include and a function call "add complexity". By that reasoning, writing any code is adding complexity, and then the question is not whether code is complex (because it all would be), and only whether reviewers choose to evoke a "code complexity" argument. The llvm project has lots of complexity, and I don't believe this is an example of it.

I appreciate you replying, and I won't take up any more time.

[MaskRay]

In D122924#3431334, @kastiglione wrote:

I don't agree that an #include and a function call "add complexity". By that reasoning, writing any code is adding complexity, and then the question is not whether code is complex (because it all would be), and only whether reviewers choose to evoke a "code complexity" argument. The llvm project has lots of complexity, and I don't believe this is an example of it.

I appreciate you replying, and I won't take up any more time.

Then have you read my points about consistency and orthogonality?

lld/tools/lld/lld.cpp

 // lld can be invoked as "lld" along with "-flavor" option. This is for
 // backward compatibility and not recommended.
 //
 //===----------------------------------------------------------------------===//
 
 #include "lld/Common/Driver.h"
 #include "lld/Common/ErrorHandler.h"
 #include "lld/Common/Memory.h"
+#include "lld/Common/Version.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/CrashRecoveryContext.h"
 #include "llvm/Support/Host.h"
else if (f == Gnu)
       return elf::link;
     else if (f == WinLink)
       return coff::link;
     else if (f == Darwin)
       return macho::link;
     else if (f == Wasm)
       return lld::wasm::link;
     else
-      die("lld is a generic driver.\n"
-          "Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld"
-          " (WebAssembly) instead");
+      die("lld is a generic driver. (" + getLLDVersion() +
+          ")\nInvoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), "
+          "wasm-ld (WebAssembly) instead");
   }();
   // Run the driver. If an error occurs, false will be returned.
   bool r = link(args, stdoutOS, stderrOS, exitEarly, inTestOutputDisabled);
 
   // Call exit() if we can to avoid calling destructors.
   if (exitEarly)
     exitLld(!r ? 1 : 0);