This patch takes the IO redirection logic from ScriptInterpreterPython and moves it into the interpreter library so that it can be used by other script interpreters. I've turned it into a RAII object so that we don't have to worry about cleaning up in the calling code.
Details
- Reviewers
labath - Group Reviewers
Restricted Project - Commits
- rGd79273c941d5: [lldb/ScriptInterpreter] Extract IO redirection logic
Diff Detail
Event Timeline
Sounds like a good idea, just the error handling needs to be done carefully.
lldb/source/Interpreter/ScriptInterpreter.cpp | ||
---|---|---|
171 | I'm pretty sure this will trigger an assertion about overwriting an unchecked error. One way to handle this would be to wrap the error in an ErrorAsOutParameter object, but I think it's better to replace the constructor with a static factory function returning an Expected<unique_ptr>. |
lldb/source/Interpreter/ScriptInterpreter.cpp | ||
---|---|---|
171 | That's how I did it at first, but I found this more elegant and compact. Maybe the ErrorAsOutParameter would tip the scales. I'll change it back to a factory. |
I think this looks good, though it looks like you have uploaded an partial patch...
lldb/include/lldb/Interpreter/ScriptInterpreter.h | ||
---|---|---|
37–38 | If that works, I suppose it's fine. But I wouldn't be surprised if this trick backfires on some STL implementations. I think that making an exception for make_unique on classes with private constructors is fine (we already have a bunch of classes like that)... | |
lldb/source/Interpreter/ScriptInterpreter.cpp | ||
111–211 | Given that none of this fails (though maybe it should), I think it would be cleaner to keep it in the constructor. You can still keep the static factory thing as a wrapper if you want symmetry. | |
111–211 | Similarly, I would find this better as return std::make_unique<ScriptInterpreterIORedirect>(std::move(nullin.get()), std::move(nullout.get())) (with an appropriate constructor. Mainly because then I don't need to worry about what will the destructor of ScriptInterpreterIORedirect do if we return with the object in an partially initialized state. |
lldb/include/lldb/Interpreter/ScriptInterpreter.h | ||
---|---|---|
37–38 | BTW, i've just thought of another reason to not do the friend thingy -- making std::make_unique allows _anyone_ to construct this class via std::make_unique, which defeats the purpose of making the constructor private. OTOH, if we can successfully separate the fallible and infallible parts of the construction, then making the infallible part (constructor) public may not be that dangerous. For example, in this case, making the (FileUP, FileUP) constructor public might be ok. |
If that works, I suppose it's fine. But I wouldn't be surprised if this trick backfires on some STL implementations.
I think that making an exception for make_unique on classes with private constructors is fine (we already have a bunch of classes like that)...