Last round of preliminary cleanup in my refactoring of aliases.

The next step is to actually turn CommandAlias into a full-blown CommandObject citizen.

This is tricky given the current architecture of the CommandInterpreter but I think I have found a reasonable path forward.
The current plan is to make class CommandAlias : public CommandObject, and have all the several GetCommand calls not actually traverse through the alias to the underlying command object
The only times that an alias will be traversed are:
a) execution; when time comes to run an alias, I will just grab the underlying command and options, and make the interpreter execute that according to its current algorithm
b) subcommand traversal; if one has an alias to a multiword command, grabbing a subcommand will see through to the subcommand

Other operations, e.g. command listing, command names, command helps, ..., will all use the alias directly. This will, in turn, lead to the removal of the separate alias dictionary, and just mix user commands and aliases in one map

llvm-svn: 262986

1 files changed, 1 insertions, 1 deletions

diff --git a/lldb/source/Commands/CommandObjectHelp.cpp b/lldb/source/Commands/CommandObjectHelp.cpp
index 9f8af301352..d84de5423d0 100644
--- a/lldb/source/Commands/CommandObjectHelp.cpp
+++ b/lldb/source/Commands/CommandObjectHelp.cpp
@@ -189,7 +189,7 @@ CommandObjectHelp::DoExecute (Args& command, CommandReturnObject &result)
             if (is_alias_command)
             {
                 StreamString sstr;
-                m_interpreter.GetAlias(alias_name.c_str())->GetAliasHelp(sstr);
+                m_interpreter.GetAlias(alias_name.c_str())->GetAliasExpansion(sstr);
                 result.GetOutputStream().Printf ("\n'%s' is an abbreviation for %s\n", alias_name.c_str(), sstr.GetData());
             }
         }