This is an archive of the discontinued LLVM Phabricator instance.

Refactor parsing of option lists with a raw string suffix.
ClosedPublic

Authored by teemperor on Jul 9 2018, 4:31 PM.

Details

Summary

A subset of the LLDB commands follows this command line interface style:

<command name> [arguments] -- <string suffix>

The parsing code for this interface has been so far been duplicated into the different
command objects which makes it hard to maintain and reuse elsewhere.

This patches improves the situation by adding a OptionsWithRaw class that centralizes
the parsing logic and allows easier testing. The different commands now just call this class to
extract the arguments and the raw suffix from the provided user input.

Diff Detail

Repository
rL LLVM

Event Timeline

teemperor created this revision.Jul 9 2018, 4:31 PM

This is great. The only quibble I have is that I would really like to restrict ArgsWithSuffix to be "OptionsWithSuffix". I don't think we want to add:

(lldb) some_cmd -f 0 -g 0 SomeArg OtherArg -- raw string

That seems unnecessarily general, and not terribly helpful. So at minimum I'd suggest calling the new class "OptionsWithSuffix" or even "OptionsWithRaw" since CommandObjectRaw will be the main user of this.

Note, you half enforce that at present because you require the first word of the argument list to be "-" for there to be any argument parsing at all. If you can think of a good way of checking that there weren't errant trailing args before the "--" that's a bonus, though it might be good enough to just document this as the required behavior...

teemperor updated this revision to Diff 154862.Jul 10 2018, 1:09 PM
teemperor retitled this revision from Refactor parsing of argument lists with a raw string suffix. to Refactor parsing of option lists with a raw string suffix..
teemperor edited the summary of this revision. (Show Details)
  • Renamed class to OptionsWithRaw
  • Changed documentation a bit that it becomes clear this class is more about about parsing command line options.

@jingham Yeah, the class became more option specific while I was trying to get the existing code working. I'm not sure if we have a way to improve the parsing, as depending on the command the input is very ambiguous (e.g. expr -i0 * -- i can really be both from the point of the parser). The current code just keeps the behavior of the existing code (which is ok, as that's not the thing the patch wants to fix).

jingham accepted this revision.Jul 10 2018, 1:19 PM

That looks good.

This revision is now accepted and ready to land.Jul 10 2018, 1:19 PM
This revision was automatically updated to reflect the committed changes.