This is an archive of the discontinued LLVM Phabricator instance.

[Settings] Make "settings set" without a value equivalent to "settings clear"
ClosedPublic

Authored by JDevlieghere on Oct 2 2018, 1:58 AM.

Details

Summary

I want to make providing no value to setting set <setting> equivalent to clearing that setting: settings clear <setting>. The motivation is D52651 that allows settings to be written to and read from a file. Not all settings have a default or empty value that can be read again, for example enums where the default is not valid value (unknown for target.language) or strings where the empty string is not equal to an empty option.

  • One possible alternative is giving every option an explicit and valid default. From a user perspective I don't think this is a good idea. For target.language it doesn't make sense to have unknown in the list of options.
  • The alternative is changing all the dump methods to print settings clear <setting> for the eDumpOptionCommand. Personally I don't like adding too much logic to the dump methods.

I definitely share the feeling that it's unfortunate to have two methods of doing the same thing. However, I don't think this behavior is counter intuitive and a reasonable trade-off given the current situation.

Diff Detail

Event Timeline

jingham added a subscriber: jingham.Oct 2 2018, 9:50 AM

Would it be possible for the exporter to notice empty settings and write "settings clear" instead? I'm worried that if you have a complicated setting, and the you do:

(lldb) settings set target.some-complex-setting

and decide you are wrong, you don't want to change the complex setting, then you have to know to delete the text - hitting a return is actually destructive.

Would it be possible for the exporter to notice empty settings and write "settings clear" instead?

I don't think we can if we want to re-use the existing dump infrastructure, unless there's a way to ask a Property if is empty/has a default value?

I'm worried that if you have a complicated setting, and the you do:

(lldb) settings set target.some-complex-setting

and decide you are wrong, you don't want to change the complex setting, then you have to know to delete the text - hitting a return is actually destructive.

This sounds like a very specific issue, though. You have the same problem if the value is something like a string and the user accidentally types one more character. What kind of scenario do you have in mind where a user would be able to type the command but not know how to delete it? I'm definitely not saying it's not a valid reason to consider alternatives and the current behavior is nice, but do you consider this a showstopper?

I'm thinking of the scenario where you type:

(lldb) settings set target.run-args

and then decide you didn't want to change the run-args after all. Before this change hitting return used to be a way to dismiss the settings operation, and that actually seems a pretty natural thing to do - especially given that there is a "clear" operation.

And more, I just like operations to be explicit and not have overloads like "settings set property" == "settings clear property".

Only clear setting when the force flag is set (as suggested offline by @jingham).

jingham accepted this revision.Oct 24 2018, 2:47 PM

That looks fine.

This revision is now accepted and ready to land.Oct 24 2018, 2:47 PM
This revision was automatically updated to reflect the committed changes.