This is an archive of the discontinued LLVM Phabricator instance.

[opt] Change the parameter of OptTable::PrintHelp from Name to Usage and don't append "[options] <inputs>"
ClosedPublic

Authored by MaskRay on Aug 20 2018, 4:18 PM.

Details

Summary

Before, "[options] <inputs>" is unconditionally appended to the Name parameter. It is more flexible to change its semantic to Usage and let user customize the usage line.

% llvm-objcopy
...
USAGE: llvm-objcopy <input> [ <output> ] [options] <inputs>

With this patch:

% llvm-objcopy
...
USAGE: llvm-objcopy input [output]

Diff Detail

Event Timeline

MaskRay created this revision.Aug 20 2018, 4:18 PM
rupprecht requested changes to this revision.Aug 21 2018, 10:38 PM

Some uses of this already use a space and probably don't want this behavior -- e.g. tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp invokes this w/ "clang -cc1". (There are a few others).

It seems like just checking for a space isn't a perfect signal for if this is a tool name or a full usage. Maybe there's another way, such as configuring (via a method or constructor arg in OptTable) whether the tool supports multiple inputs or multiple outputs?

Whatever you come up with, can you add a test case to unittests/Option/OptionParsingTest.cpp?

This revision now requires changes to proceed.Aug 21 2018, 10:38 PM
MaskRay updated this revision to Diff 161993.Aug 22 2018, 10:29 AM

Add test to unittests/Option/OptionParsingTest.cpp

tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp invokes this w/ "clang -cc1".

Thanks for pointing this out. The other one is clang -cc1as. I think the best way is to make the two instances explicit https://reviews.llvm.org/D51109
I have checked other references and think they are fine with the OptTable::PrintHelp change.

Will it be good to update all the call sites of OptTable::PrintHelp to add "[options] <inputs>" explicitly?

I'm still against having a space in the string as the basis for interpreting it as a usage parameter. It's way too surprising.

include/llvm/Option/OptTable.h
230

What about including optional usage as a separate arg? e.g.

void PrintHelp(raw_ostream &OS, StringRef Name, StringRef Title,
               StringRef Usage="", ...) {
  OS << "USAGE: " << Name << (!Usage.empty() ? Usage : " [options] <inputs>") << '\n';
  ...
}

It's yet another method parameter, but there's zero magic involved.

MaskRay added inline comments.Aug 30 2018, 11:28 AM
include/llvm/Option/OptTable.h
230

This can be temporary. If https://reviews.llvm.org/D51109 looks good, I can add "[options] <inputs>" explicitly for all call sites.

MaskRay updated this revision to Diff 168892.Oct 9 2018, 3:53 PM

Change the parameter to Usage

MaskRay updated this revision to Diff 168893.Oct 9 2018, 3:54 PM

Update title

MaskRay retitled this revision from [opt] Make OptTable::PrintHelp append "[options] <inputs>" conditionally to [opt] Change the parameter of OptTable::PrintHelp from Name to Usage and don't append "[options] <inputs>".Oct 9 2018, 3:55 PM
MaskRay updated this revision to Diff 168911.Oct 9 2018, 4:57 PM
MaskRay marked an inline comment as done.
MaskRay edited the summary of this revision. (Show Details)
MaskRay removed a reviewer: dblaikie.
MaskRay removed a subscriber: jakehehrlich.

.

rupprecht accepted this revision.Oct 9 2018, 5:15 PM
rupprecht added inline comments.
tools/llvm-objcopy/llvm-objcopy.cpp
900 ↗(On Diff #168911)

extract this to a static const char[] like for strip below

This revision is now accepted and ready to land.Oct 9 2018, 5:15 PM

.

Please don't remove subscribers like this. People setup Herald rules to make sure they're notified of any changes. Also, are you sure you've added all the needed reviewers for this? This is touching a lot of tools and this is not really the diverse group of reviewers I'd expect to give the ok on this sort of stuff.

The intent of this change seems non-offensive to me and I'm generically fine with it.

Also "<inputs>" seems better than "files..." to me.

tools/llvm-objcopy/llvm-objcopy.cpp
900 ↗(On Diff #168911)

Maybe we should add "[options]" before "input"

Also, I think I'd prefer "<input>" to "input"

1042 ↗(On Diff #168911)

I'd prefer "<inputs>" to "file..."