This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Rewrite the 'settings set' command parser
Needs RevisionPublic

Authored by teemperor on Feb 11 2021, 6:12 AM.

Details

Reviewers
jingham
Summary

For convenience reasons the 'settings set' commands parsing logic is hand-written and doesn't strictly follow
the usual LLDB command rules. The help page gives the following syntax:

settings set [-f] [-g <filename>] -- <setting-variable-name> <value>
settings set <setting-variable-name> <value>

For the most part LLDB follows that syntax, but the current parser for the command syntax has some strange quirks
that are probably best demonstrated with some examples:

# Quotes break the parser
(lldb) settings set "prompt" foo
error: mismatched quotes

# Arguments starting with '-' behind the property name are recognized as command flags.
(lldb) settings set target.run-args -v
error: unknown or ambiguous option

# Even when working around via `--`, the settings write/read functionality doesn't support it.
(lldb) settings set -- target.run-args -v
(lldb) settings show target.run-args 
target.run-args (arguments) =
  [0]: "-v"
(lldb) settings write -f ~/set
(lldb) settings read -f ~/set
Executing commands in '/Users/teemperor/set'.
error: unknown or ambiguous option

# Also using the `-g` with a filename that contains the property name leads to some strange results.
(lldb) settings set -g ~/prompt-settings prompt foo
-settings prompt foo # <- this is the new prompt

We could just change the syntax to what the other 'raw' commands are using, but that would obviously
break everyone's script and all the settings files LLDB has generated for users.

So instead this is a partial rewrite of the old settings parser that tries to support the previous syntax
(with some minor exceptions) but also address the issues above.

In essence the patch does two things:

First we incrementally try to parse the argument list passed by the user until we find the property name.
Only the flags up until the property name are considered command flags as we promised in the help page.
This should fix issues related to passing values starting with - leading to error: unknown or ambiguous option.

Afterwards we explicitly hop over all the command flags we found in the first part instead
of just searching the input string for the property name. This way having the property name
occur in one of the arguments (e.g. -g path/to/property-name.settings) doesn't cause LLDB
to write set the property to whatever follows the first "property name" occurrence.

From what I can see the only use case this breaks is clearing a property value by doing settings set <name> -f
(as now we treat the -f as the value that <name> should be set to).

Diff Detail

Event Timeline

teemperor requested review of this revision.Feb 11 2021, 6:12 AM
teemperor created this revision.
jingham accepted this revision.Feb 11 2021, 11:48 AM

LGTM, a few trivial comment comments.

lldb/source/Commands/CommandObjectSettings.cpp
169

This is a bit of a weird example, since it doesn't in fact have a settings name. Did you mean to have some settings name between "my-command-args" and "-o"?

176

IIUC, the tricky bit of this routine is that you can't just look at the argument words one by one till you find a setting name, because you might have a setting name as an option value. That's why you have to do this progressive "truncate and parse" strategy. Be a good idea to mention that so somebody doesn't "simplify" your code for you later on.

You explain this below when you actually pull out the settings value. Maybe just refer to that comment?

178

Missing a verb.

219

This wasn't part of your changes, but it's a bit weird to call a property name a "variable" name. Could you fix this while you are here?

This revision is now accepted and ready to land.Feb 11 2021, 11:48 AM
jingham requested changes to this revision.Feb 11 2021, 11:58 AM

One confusion that could arise, however, is that since this is a CommandObjectRaw command, we print this at the end of the help:

This command takes options and free-form arguments.  If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the command options and the beginning of
the arguments.

which isn't actually true. It would be good to override that automatic not-helpful help insertion. Overriding IsDashDashCommand on the CommandObjectSettingsSet command should turn this off, if I'm reading the code correctly.

This revision now requires changes to proceed.Feb 11 2021, 11:58 AM