This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Compute fully qualified command names in FindCommandsForApropos
ClosedPublic

Authored by kastiglione on Jan 1 2022, 8:59 PM.

Details

Summary

Fixes incomplete command names in apropos results.

The full command names given by apropos have come from command name string
literals given to CommandObject constructors. For most commands, this has
been accurate, but some commands have incorrect strings. This results in
apropos output that doesn't tell the user the full command name they might
want learn more about. These strings can be fixed.

There's a seperate issue that can't be fixed as easily: plugin commands. With
the way they're implemented, plugin commands have to exclude the root command
from their command name string. To illustrate, the language objc subcommand
has to set its command name string to "objc", which results in apropos printing
results as objc ... instead of language objc ....

To fix both of these issues, this commit changes FindCommandsForApropos to
derive the fully qualified command name using the keys of subcommand maps.

Diff Detail

Event Timeline

kastiglione requested review of this revision.Jan 1 2022, 8:59 PM
kastiglione created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 1 2022, 8:59 PM
kastiglione retitled this revision from [lldb] Compute fully qualified command names in FindCommandsForApropos (NFC) to [lldb] Compute fully qualified command names in FindCommandsForApropos.Jan 1 2022, 8:59 PM

Use std::move

JDevlieghere added inline comments.Jan 5 2022, 9:50 AM
lldb/source/Interpreter/CommandInterpreter.cpp
2866

It's not obvious what type qualified_name is. I would either do:

std::string qualified_name = (command_name + " " + subcommand_name).str();

or

auto qualified_name = std::string(command_name + " " + subcommand_name);
kastiglione added inline comments.Jan 5 2022, 11:06 AM
lldb/source/Interpreter/CommandInterpreter.cpp
2866

As you've given feedback on use of auto before, should we document some standards around auto? It seems to vary in the code, and from person to person.

I'm cool with explicit std::string, but I think a few bits of context here do indicate it's a string type (ex use of .str(), use of + and a string literal, being passed to AppendString()). I'm thinking that some of these could be documented as either sufficient or insufficient for auto.

Somewhat separately, what do you think about adding AppendString(const Twine&) (D116682) and then making this:

commands_found.AppendString(command_name + " " + subcommand_name);
JDevlieghere added inline comments.Jan 5 2022, 11:55 AM
lldb/source/Interpreter/CommandInterpreter.cpp
2866

The LLVM Coding Standards have a section on auto: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable.

If it were any other type, I might agree with your argument, but we have a bunch of "string" types (std::string, llvm::StringRef and lldb_private::ConstString being the usual suspects) making it non-obvious.

augusto2112 accepted this revision.Jan 5 2022, 12:03 PM

I liked the small cleanups in the code as well!

This revision is now accepted and ready to land.Jan 5 2022, 12:03 PM
kastiglione added inline comments.Jan 5 2022, 12:35 PM
lldb/source/Interpreter/CommandInterpreter.cpp
2866

from the doc:

or other places where the type is already obvious from the context.

I find this leaves a lot of room for interpretation, ideally it would be more precise. In the mean time I will switch to string but I bet this isn't our last conversation.

explicit std::string type

JDevlieghere accepted this revision.Jan 5 2022, 1:13 PM

Thanks!