[lldb-dev] Custom arguments completion for commands created by LLDB plugins
Jim Ingham via lldb-dev
lldb-dev at lists.llvm.org
Mon Oct 7 11:30:08 PDT 2019
> On Oct 7, 2019, at 3:35 AM, Raphael “Teemperor” Isemann via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> To my knowledge there is no way to have completions for custom commands. If you just want completions for nested commands (e.g., having a “custom add” and “custom remove” commands and want completions for completing “add” and “remove”), then this should work if you build the nested command using the SBCommand::Add[Multiword]Command functions. However, that won’t allow you to provide arbitrary completions for arguments.
> Regarding your planned change: Adding a new virtual method would break the ABI of SBCommandPluginInterface and the SBAPI is supposed to have a stable ABI. So I guess we have two options.
> 1. break the ABI for this class and somehow let people know they need to recompile their plugins for the next release.
> 2. add a new overload to the existing AddCommand methods and allow passing some kind of interface for completions. Custom command classes just inherit from both interfaces if they want to provide their own completions.
I don't think that's the right way to handle completions for custom commands. Custom commands already suffer from the fact that they have to parse their own arguments and options, so they don't work like lldb commands. We can't do their help correctly because we don't know this info, and if they used any of the common completion types, they would have to reimplement them.
Instead of adding another ad hoc behavior that the builtin lldb commands don't use, we should really allow custom commands to be regular LLDB commands, by having some API the command can call when added to set up its arguments and options. The these could get built in the command table just like the built-in lldb commands, and lldb could handle the help and completions. For all the known completion types, you could then just say "This is a file" or "This is a symbol" etc. and lldb would handle the completion. And if you have a custom completion callback for some argument, you would just provide a function pointer to the "AddOption" or "AddArgument" API's.
> I’m fine with either option, but if we end up going for option 1, then IMHO we might as well change the API of this class as it’s current DoExecute function is just wrong. It returns an undocumented ‘bool’ value which seems to provide redundant information to the success status of the result parameter and we pass it a `char **` parameter which actually has `const char **` semantics as changing it corrupts LLDB’s internal `Args` data structure.
> In any case I would prefer if we wait with landing this API until I fully cleaned up LLDB's completion logic and we got around to set in stone the new HandleCompletion API (which gives us an overview of what kind of completions clients want to receive and in what format). Both should happen for LLDB 10 if everything goes right, so this shouldn’t delay adding this feature.
> - Raphael
> (Resending this as my other email got blocked by lldb-dev somehow)
>> On 6. Oct 2019, at 02:55, Matheus Marchini via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> Is there a way to create custom argument completion handlers for
>> commands introduced by LLDB plugins? I want to add completion for some
>> commands on llnode (https://github.com/nodejs/llnode), but I couldn't
>> find a way to do so using the C++ public API.
>> Based on this comment
>> I was expecting some API to add custom completion handlers, but I
>> guess the comment is intended for internal development only?
>> If there isn't a way to do that today, I'm thinking about adding it as
>> a new method to SBCommandPluginInterface, unless someone objects to
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
More information about the lldb-dev