This is an archive of the discontinued LLVM Phabricator instance.

[llvm] [CommandLine] Do not suggest really hidden opts in nearest lookup
ClosedPublic

Authored by mgorny on Jun 17 2020, 3:29 AM.

Details

Summary

Skip 'really hidden' options when performing lookup of the nearest
option when invalid option was passed. Since these options aren't even
documented in --help-hidden, it seems inconsistent to suggest them
to users.

This fixes clang-tools-extra test failures due to unexpected suggestions
when linking the tools to LLVM dylib (that provides more options than
the subset of LLVM libraries linked directly).

Diff Detail

Event Timeline

mgorny created this revision.Jun 17 2020, 3:29 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 17 2020, 3:29 AM
Herald added a subscriber: hiraditya. · View Herald Transcript

Sounds like a good idea to me.

Could you extend the "OptionErrorMessageSuggest" test in llvm/unittests/Support/CommandLineTest.cpp to cover this case?

llvm/lib/Support/CommandLine.cpp
595

Rather than not considering them (and offering a worse option, which may be confusing) you might consider checking Best after the loop so we just offer no suggestion if the best one is hidden.

Not sure which behavior is better, up to you.

mgorny marked an inline comment as done.Jun 17 2020, 6:48 AM
mgorny added inline comments.
llvm/lib/Support/CommandLine.cpp
595

The clang-tools-extra tests in question rely on having the 'next best' served.

I think the current behavior is more predictable, as adding new 'really hidden' options won't cause the current suggestions to suddenly disappear.

(I'm working on the test)

njames93 added inline comments.Jun 17 2020, 7:18 AM
llvm/lib/Support/CommandLine.cpp
595

Are they the ones added in D80879. If it is, the CHECK-NEXT lines in there could probably be done away with anyway. The important part was making sure it didn't crash.

However tests in llvm/unittests/Support/CommandLineTests should be added for this change.

595

I'm not too fond of Sams suggestion as it isn't great for the case when a really hidden option had a slightly shorter distanced name to another non hidden option, You will lose the valid option suggestion.
I kind of prefer the way of ignoring really hidden options, but putting an upper limit on the distance for suggested changes. I almost feel like the distance should be a function of the OptionLength - A 50 character option differing by 2 characters has much more confidence than a 3 character option differing by 2. Can't think of a good mapping for it though, My first suggestion would be based on the square root of the length

sammccall accepted this revision.Jun 17 2020, 7:40 AM

I don't feel strongly about the inside/outside loop, let's stick with what you've proposed then.

LG with a test.

This revision is now accepted and ready to land.Jun 17 2020, 7:40 AM
mgorny updated this revision to Diff 271379.Jun 17 2020, 8:38 AM

Added a test that adds a hidden option that is closer to argv. Confirmed that it fails without the change, passes with the change.

I don't feel strongly about the inside/outside loop, let's stick with what you've proposed then.

LG with a test.

Thanks. Could you take a quick look at the test, just to be sure?

lattner accepted this revision.Jun 17 2020, 8:57 AM

Makes sense, thanks!

This revision was automatically updated to reflect the committed changes.