This is an archive of the discontinued LLVM Phabricator instance.

[lldb/ScriptInterpreter] Extract IO redirection logic and move it out of ScriptInterpreterPython (NFC)
ClosedPublic

Authored by JDevlieghere on Jun 23 2020, 10:34 AM.

Details

Reviewers
labath
Group Reviewers
Restricted Project
Commits
rGd79273c941d5: [lldb/ScriptInterpreter] Extract IO redirection logic
Summary

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.

Diff Detail

Event Timeline

JDevlieghere created this revision.Jun 23 2020, 10:34 AM

Consume the error when the result pointer is null.

Sounds like a good idea, just the error handling needs to be done carefully.

lldb/source/Interpreter/ScriptInterpreter.cpp
170

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>.

JDevlieghere marked an inline comment as done.Jun 24 2020, 8:47 AM
JDevlieghere added inline comments.
lldb/source/Interpreter/ScriptInterpreter.cpp
170

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.

This now has a small function change w.r.t. the error message.

labath accepted this revision.Jun 25 2020, 1:23 AM

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
108–109

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.

108–109

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.

This revision is now accepted and ready to land.Jun 25 2020, 1:23 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 25 2020, 10:14 AM
labath added inline comments.Jun 26 2020, 1:56 AM
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.