[PATCH] D61870: Make cl::HideUnrelatedOptions more flexible

Wed May 15 14:05:17 PDT 2019

hintonda added a comment.

In D61870#1503529 <https://reviews.llvm.org/D61870#1503529>, @beanz wrote:

> In D61870#1503490 <https://reviews.llvm.org/D61870#1503490>, @serge-sans-paille wrote:
>
> > @beanz 
> >  As pointed out by @hintonda, current default argument is *never* explicitly used in the codebase.
>
>
> Yea, but that's going to change as soon as you start calling this in more places. Have you looked at how this might apply to a tool that has sub-commands? My concern is that the ordering of default parameters in functions that have more than one really needs to be in the order of decreasing likelihood of whether or not it will be overridden. By my count we have 2 tools with subcommands that account for 16 SubCommand, and you have one example of overriding the enum. At the moment it seems to me like overriding the SubCommand may be the more common case.

Since no one is calling `cl::HideUnrelatedOptions` with specific SubCommands, it's hard to say.  However, `llvm-pdbutil` makes extensive use of SubCommands, it seems like a good test-case.

The basic `--help-hidden` output includes a lot of additional general options, though I haven't investigated where they come from.  However, the `--help-hidden` output for a specific SubCommand does not include those options, so I'm not sure this is a problem (I'll investigate exactly how it all works and report back).  I'm temped to think SubCommands aren't really needed in this API, since only the Options for the SubCommand are printed anyway.  Again, I'll investigate and report back.

But the biggest issue is that `--help-hidden` always displays all the Categories every time `--help-hidden` is passed, even if they are empty and wouldn't normally apply.  I think that's a bug.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61870/new/

https://reviews.llvm.org/D61870