This adds an RunCommandInterpreter overload that returns an instance of SBCommandInterpreterRunResults. The goal is to avoid having to add more and more overloads when we need more output arguments.
Details
Diff Detail
- Repository
- rLLDB LLDB
Event Timeline
Yeah, anytime you see API calls that have many arguments it is a good idea to switch to this kind of API as adding accessors doesn't require us to change the API. We did this with SBTarget::Attach() and SBTarget::Launch() after having many variants of these functions...
Sorry, missed the fact that the new class had ivars. For ABI stability, we can't modify the number of ivars since we need the class size of SBCommandInterpreterRunResults to never change even if we add more things to it.
lldb/include/lldb/API/SBCommandInterpreterRunOptions.h | ||
---|---|---|
90–93 | We need to abstract these, they can't be in the lldb::SB class. So you just need to make an opaque class that contains these ivar and use a std::unique_ptr to the opaque class. |
lldb/include/lldb/API/SBCommandInterpreterRunOptions.h | ||
---|---|---|
93 | like how SBCommandInterpreterRunOptions does it above with its ivar "m_opaque_up" that never changes size |
Here I would be interested to know whether the "stop reasons" are mutually exclusive? It sounds like they should be...
And if they are, it seems that a better way to express this would be via something like GetRunResult which returns Success, or InferiorCrash, or CommandError, or QuitRequested. Other reasons can be added to the enum later, if needed...
We need to abstract these, they can't be in the lldb::SB class. So you just need to make an opaque class that contains these ivar and use a std::unique_ptr to the opaque class.