[Lldb-commits] [lldb] [lldb] Add lldb.summary and lldb.synthetic decorators (PR #195351)

[Med Ismail Bennani via lldb-commits]

medismailben wrote:

> This [comment](https://github.com/llvm/llvm-project/pull/195351#discussion_r3186174146) by @JDevlieghere gave me an idea of another way to implement this, a way which works similarly to `@lldb.command` (i.e. immediate not deferred `HandleCommand`).
> 
> Here's a slightly simplified version of how the `summary` decorator would look:
> 
> ```python
> def summary(type_name):
>     interp = debugger.GetCommandInterpreter()
>     def decorator(func):
>         qualified = f"{func.__module__}.{func.__qualname__}"
>         cmd = f"type summary add -F {qualified} {type_name}"
>         result = lldb.SBCommandReturnObject()
>         interp.HandleCommand(cmd, result)
>         if err := result.GetError():
>             if "class does not exist" not in err:
>                 print(err, file=sys.stderr)
>         return func
>     return decorator
> ```
> 
> The reason I didn't initially use an immediate `HandleCommand` is because `type summary add` and `type synthetic add` both emit warnings if the function/class does not exist. But, by using `SBCommandInterpreter.HandleCommand` (instead of `SBDebugger`), its output can be captured (`SBCommandReturnObject`), giving the decorator the opportunity to ignore warnings known to be a false positive.
> 
> So, @jimingham, @medismailben, @JDevlieghere: should I update this PR to something like the above?

I like this approach, but I'm wondering if it wouldn't be better to raise an exception in the decorator if the CRO has an error ? Would that be a better user-experience ?

https://github.com/llvm/llvm-project/pull/195351