This is an archive of the discontinued LLVM Phabricator instance.

[lld] Add version info to generic driver output
AbandonedPublic

Authored by keith on Apr 1 2022, 10:56 AM.

Details

Reviewers
MaskRay
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

Diff Detail

Event Timeline

keith created this revision.Apr 1 2022, 10:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 1 2022, 10:56 AM
keith requested review of this revision.Apr 1 2022, 10:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 1 2022, 10:56 AM
keith updated this revision to Diff 420374.Apr 4 2022, 9:09 PM

Improve formatting

keith edited the summary of this revision. (Show Details)Apr 4 2022, 9:10 PM

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 added a comment.Apr 4 2022, 9:27 PM

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

MaskRay added a comment.EditedApr 4 2022, 10:10 PM

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 added a comment.Apr 4 2022, 10:14 PM

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.

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.

keith abandoned this revision.Apr 5 2022, 5:18 PM

@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 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.

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.

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?