Differential D80165
[lldb/Driver] Fix handling on positional arguments Authored by JDevlieghere on May 18 2020, 3:13 PM.
Details Before the transition to libOption it was possible to specify arguments for the inferior without -- as long as they didn't start with a dash. For example, the following invocations should all behave the same: $ lldb inferior inferior-arg $ lldb inferior -- inferior-arg $ lldb -- inferior inferior-arg This patch fixes that behavior and adds a test to cover the different combinations.
Diff Detail Event TimelineComment Actions One thing the current approach allows is foo bar -o 'run' baz which will set target.run-args to "bar" "baz" . I guess that's not really desirable, but I'm not sure it outweighs the added complexity of tracking the beginning and thee end. Comment Actions So when talking about "prior to libOption", are we talking getopt()? I believe that getopt would have an issue with: $ lldb inferior --inferior-arg As it would not understand the argument. Or was there an intermediate llvm option parser we were using after getopt()? And BTW, getopt allows arguments and options to be interspersed: $ lldb --lldb-option1 inferior --lldb-option2=123 inferior-arg1 -- --inferior-opt=444 inferior-arg2Comment Actions Not sure why you need to track "beginning and end". Does libOption not pull out all the options (and their option values if they have them) before handing you the command line? If not, then this probably is not worth doing. But if it does, this should be straightforward since the only arguments lldb takes (prior to seeing a --) are meant to be arguments to the program when you run it. Comment Actions Apparently I misremembered the old behavior. Jim refreshed my memory about what he expects the behavior to be link. I've reworked the patch to match that. The result is actually less complex than it was before. Please ignore the old patch & description. Comment Actions Thanks for fixing this. I remember running into this a couple of times, but I never got around to do something about it...
Comment Actions I agree with Pavel, reporting an error and exiting seems like a good behavior. When I mistype a command line option, I generally immediately quit lldb, up-arrow and fix and resubmit, so this would save keystrokes. We should make sure if we do exit that we don't output any other text that would obscure the error message. It should be easy to spot the error both so you can easily fix it and to prevent you from typing lldb commands into your shell. If libOption had a "nearest option name to the one you typed" facility that would be useful in this case as well. Does anybody remember what gdb does when you mistype a command-line option? We're not at all required to model their behavior, but it would be interesting to consider. Comment Actions That facility exists. Clang uses it for command-line "fix-its". I am not sure what it takes to make use of it.
$ gdb -foobar gdb: unrecognized option '-foobar' Use `gdb --help' for a complete list of options. Comment Actions Jonas said this wasn't part of libOption, but was done by hand in clang.
You omitted the bit of text that would show whether it quit or not... Comment Actions Oh, that's too bad.
It did quit. With exit code 1. :) | ||||||||||||||||||
Unrelated to this patch, but.. do we actually want this behavior? I don't think these were just "warnings" before libOption. Given that clang treats (at least some) unknown options as errors, I'm guessing there must be some libOption knob for controlling the behavior of this...