The primary motivation for this is to add another dimension to the Swift LLDB test matrix, but this seems generally useful.
Details
Diff Detail
Event Timeline
lldb/packages/Python/lldbsuite/test/configuration.py | ||
---|---|---|
52 | To initialize settings to a empty dictionary this should be {} or dict(). |
Seems reasonable.
lldb/packages/Python/lldbsuite/test/configuration.py | ||
---|---|---|
52 | True, though that depends on what you really want out of this. I can see how executing the commands in the order that the user set them could be more predictable.... | |
lldb/packages/Python/lldbsuite/test/dotest.py | ||
787 | Maybe you could even put this as the default value for the settings variable? |
lldb/packages/Python/lldbsuite/test/dotest.py | ||
---|---|---|
787 | Not sure what you meant by this, but I don't think "no dynamic values" is the right setting for prefer-dynamic-value for ordinary users of lldb. For ObjC it is definitely the wrong value (too many things get passed as "id" which is not useful). But also, every time we break dynamic value determination for C++ we get lots of complaints, so I think this is a feature people really rely on. |
lldb/packages/Python/lldbsuite/test/dotest.py | ||
---|---|---|
787 | I just meant putting settings = [("target.prefer-dynamic-value", "no-dynamic-values")] above in configuration.py. That way the setting would be applied automatically, without needing to manually call disabledynamics(). |
lldb/packages/Python/lldbsuite/test/configuration.py | ||
---|---|---|
52 | This is intentionally *not* a dictionary :-) You're supposed to be able to write --setting foo=bar --setting foo=baz and have both of them applied, in that order. |
To initialize settings to a empty dictionary this should be {} or dict().