[Lldb-commits] [PATCH] D69468: [LLDB][breakpoints] ArgInfo::count -> ArgInfo::max_positional_args

Jim Ingham via lldb-commits lldb-commits at lists.llvm.org
Mon Oct 28 10:15:25 PDT 2019


In the work I was doing with the scripted ThreadPlans & Breakpoint Callbacks, I've been introducing Status objects into these calls in python-wrapper.swig (usually you have to start from the ScriptInterpreter API's, so we can report errors.  That way I could catch errors with wrong number of arguments and the like.  Whenever that's possible it seems preferable.

Jim


> On Oct 28, 2019, at 7:28 AM, Pavel Labath via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> labath added inline comments.
> 
> 
> ================
> Comment at: lldb/scripts/Python/python-wrapper.swig:64
> 
> +    unsigned max_positional_args = PythonCallable::ArgInfo::UNBOUNDED;
> +    if (auto arg_info = pfunc.GetArgInfo()) {
> ----------------
> lawrence_danna wrote:
>> labath wrote:
>>> Is there any case where fetching the argument info will fail, but we still can successfully call the target object? Should we just bail out here?
>> probably not?     My thinking is that since there's no meaningful way to return an error from this function we may as well try to call it and let the exception get logged.   But I dunno.    Should I change it?
> Hmm... In that case, I think it would be better to print the error which caused the ArgInfo fetching to fail. Given that, in the new way of doing things, the `PyErr_Cleaner` object is not going to work anyway, we might as well use this opportunity to create a different mechanism for printing exceptions.
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D69468/new/
> 
> https://reviews.llvm.org/D69468
> 
> 
> 



More information about the lldb-commits mailing list