This patch adds FileSP versions of SetInputFile(),
SetOutputFile, and SetErrorFile(). SWIG will convert native
python file objects into FileSP.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/include/lldb/API/SBDebugger.h | ||
---|---|---|
97–102 | Are these really for public consumption? I would hope not, and might add then as protected and friend in any code that needs to use them? At the very least a comment specifying these are for internal use. Does SBFile not have a way to construct with a FileSP? Maybe these are not needed if that is the case? |
lldb/include/lldb/API/SBDebugger.h | ||
---|---|---|
97–102 | They are kind of for public consumption. They're impossible to use from a C++ client, because they can't see the definition of lldb_private::File. But the SWIG wrappers can bind against them. They will convert a native python file That way SetInputFile works just like SetInputFileHandle works, except it doesn't have the bugs and limitations that SetInputFileHandle has. Normally you can just use the FileSP version, and not create a SBFile. But in some cases creating a SBFile manually is required, such as if you want to control how the file object is translated from python into C++. |
lldb/include/lldb/API/SBDebugger.h | ||
---|---|---|
97–102 | If I mad them protected, with a friend declaration, the friend would have to be some name that is auto-generated by SWIG. |
lldb/include/lldb/API/SBDebugger.h | ||
---|---|---|
97–102 | @clayborg, you can see the same thing happening with FileSP already in SBFile.i, and SBCommandReturnObject.i. My plan is to convert all the FILE* interfaces in the swig files into FileSP, and ultimately delete the FILE* typemap. From python's perspective then new bindings will work the same way as the old, and the FILE* methods will still be there for C++ clients. |
Looks fine to me. The public-consumptionness of the FileSP overloads was also discussed in D68546, and I currently do not see a better solution than this one. The way I've resolved this issue for myself is to look at the FileSP argument as a placeholder for some hypothetical future feature which would allow C++ users to pass in custom file objects into lldb (i.e. do the same thing that python can do now). If/when we have that, we can replace FileSP with the new thing, and have the python objects typemap to that.
Sounds good. LGTM then. Thanks for the explanation. I was out on vacation for a week and catching up on email.
Are these really for public consumption? I would hope not, and might add then as protected and friend in any code that needs to use them? At the very least a comment specifying these are for internal use. Does SBFile not have a way to construct with a FileSP? Maybe these are not needed if that is the case?