This adds support for commands created through the API to support autorepeat.
This covers the case of single word and multiword commands.
Comprehensive tests are included as well.
Differential D77444
[commands] Support autorepeat in SBCommands wallace on Apr 3 2020, 5:21 PM. Authored by
Details This adds support for commands created through the API to support autorepeat. Comprehensive tests are included as well.
Diff Detail
Event TimelineComment Actions It's great to add this capability. But if you pass a nullptr, then the exact previous command will be repeated. That's sometimes what you want, but often not. For instance: (lldb) source list -f foo -l 10 You DON'T want those same source lines to be dumped again. The full solution would be to add an optional method to the Python class version of the command that returns the "repeat" command string. Then if that is implemented use the string it produces. There are only a couple of commands (source list being one) that actually have to make up whole new command lines for the repeat command. For most of them - like disassemble - the command with no arguments does "continue from where you left off". So then the you return just your command name for the repeat command. Maybe there's some way to add this convention in without having to go whole hog on exposing the repeat string behavior. Comment Actions For instance, maybe instead of passing in a bool, you could pass in the repeat command? So when you create the command, if you pass in None, you get no repeat, if you pass in "" you get the exact command line repeated, and if you pass in anything else, that will be the repeat command. Or maybe use an enum with "noRepeat, exactRepeat, commandNameRepeat"? Comment Actions I was thinking if auto repeat was enabled that the DoExecute would just get called again with nothing and then the plug-in could maintain any repeat commands without needing to add anything... Glad you chimed in! Comment Actions The biggest issue is maintaining the API. We can't add anything to SBCommandPluginInterface Comment Actions If we're going to be adding a new inheritable class for this feature, I'd recommend adding about half a dozen or so dummy virtual methods to it so we reserve vtable space for future expansion.
Comment Actions
Within the scope of a subcommand, the subcommand doesn't know the parent's I took a look at the existing implementations for GetRepeatCommand, and it seems I don't want to change any existing core command interpreter function, so I Another option is to provide a callback function instead of a string, but I Comment Actions Thank you for trying out gtest. I'm very happy that this is working out for you. The test looks fine -- just please move it to unittests/API (new folder) -- that's where it logically belongs as it's testing the API code (and it also avoids dangerous ODR violations resulting from linking in both liblldb and its constituent libraries). It sounds like you and Jim have mostly agreed on the way this should be implemented. I'll let you two work out any kinks there.
Comment Actions BTW, in gtest tests, the prevailing convention is to name test .cpp files according to the name of the .cpp file under test. So, in this case, that would be something like unittests/API/SBCommandInterpreterTest.cpp. I wouldn't want to take that convention to the extreme and have 10kloc test files, but until we start having more of these tests, I think we can stick to that. Comment Actions This looks good to me, except that instead of leaving all the other variants of AddCommand, they should funnel through the one that takes the most arguments. It was poor form to leave two around and more so now that there's three. I'm beginning to think we need an SBAddCommandOptions or something like that so we don't need to add yet another variant next time we want to add some flags to a command. That is a nice-to-have, however. If you are done with this change, it's okay as it stands. In retrospect, I think it would be better if the CommandInterpreter were to prepend the container commands to the repeat command string. It is bogus that multi-word commands have to know their hierarchy to emit a useful repeat command string. Prepending the containing commands would mean that command A couldn't invoke a totally different command as its repeat command. But that seems like an odd thing to do anyway. And that way a command wouldn't have to know where it is situated in the command hierarchy for the repeat command to work. That makes your test ugly, but that's not your fault (it's probably some earlier version of me's decision).
|
clang-format-diff not found in user's PATH; not linting file.