Thanks for laying this out. I don't think any of us have a brief for getopt, it was the tool at hand. Getting some fuzzy match suggestions would be nice.
Your comment about getopts reminds me, a more fundamental problem with lldb's command interpreter is that the CommandObject is stateful. So you can't actually call a command and then in the process of handling that command call back into the same command without destroying the options settings from the older invocation. We actually do this (e.g. anything that hits a breakpoint can call arbitrary lldb commands). We just luck out because most commands grab their arguments, decide what to do with them, then do the work. So the second invocation overwrites options that aren't going to get reused. But working by luck is never good... It would be much better to separate the Command definition part of the CommandObject from the Invocation part, so that one command definition could server multiple invocations. If somebody has ambition to dig into lldb's command interpreter, I'd propose this task over replacing something that works with something else that works more nicely. Jim > On Feb 12, 2018, at 2:31 AM, Pavel Labath via Phabricator > <revi...@reviews.llvm.org> wrote: > > labath added a comment. > > There are several components in the "command line parsing" > > 1. argparse: parsing a single string into the individual words (processing > quotes, backslashes, etc.) > 2. resolving the "command" part of the command line (the "frame variable" > part of "frame variable --raw-output FOO") > 3. resolving the arguments of a command (the "--raw-output FOO" part) > > These parts compose quite nicely, and can be individually replaced. I'll > briefly speak about each one : > > (1) is very specific to our interactive use case (for command line utilities, > the shell/os does the parsing for us). There also isn't anything nearly > similar in llvm (afaik). > (2) is also quite specific to how lldb commands are structured, and there > also isn't a suitable llvm replacement. This is the level at which the > "command aliases" are resolved. > (3) is a fairly generic piece of functionality -- we even implement it by > delegating to getopt (in a scarily un-thread-safe way). For this there are > *two* competing implementations in llvm: `llvm::cl` and `llvm::opt`. Of these > the first one is not suitable for our use case right now as it relies on > global variables. Making it work probably would be a bit or work. However, > using the second one should be fairly easy, and it should be generic-enough > (it's the thing that handles crazy gcc command lines). > > The reason I'm spelling it out this way is because I think you were mostly > talking about (3), but some of the difficulties Jim pointed out (command > aliases) just aren't relevant there. I don't think llvm::opt handles > "shortest match" options yet, but that should be fairly easy to add. On the > flip side, the library has recently gained argument suggestion capabilities > (`error: unknown argument '-gllbb', did you mean '-glldb'`), so we would get > that for free. Making sure tab completion works there would require a bit of > thought, but I think this should not interfere with this library too much > (after all, we use getopt now, and it does not support tab completion either). > > > Repository: > rL LLVM > > https://reviews.llvm.org/D43099 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
