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 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
