To my knowledge there is no way to have completions for custom commands. If you
just want completions for nested commands (e.g., having a “custom add” and
“custom remove” commands and want completions for completing “add” and
“remove”), then this should work if you build the nested command using
https://bugs.llvm.org/show_bug.cgi?id=43588
Bug ID: 43588
Summary: argv[0] is always passed as absolute
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Prio
> On Oct 7, 2019, at 3:35 AM, Raphael “Teemperor” Isemann via lldb-dev
> wrote:
>
> To my knowledge there is no way to have completions for custom commands. If
> you just want completions for nested commands (e.g., having a “custom add”
> and “custom remove” commands and want completions for
Nested command completion works. I want to complete parameters of
commands based on information from the debugged process (attributes of
an object, etc.).
> 1. break the ABI for this class and somehow let people know they need to
> recompile their plugins for the next release.
I'd rather not bre
Jim just ninja’d the discussion with his point that we could add methods for
adding command completions to existing commands and I actually agree that’s the
better idea (especially since this is abstracting away the actual option
parsing from the user and it can be better integrated into the cur
I have a simple C program that has printf statements.
It produces zero output.
However when it’s run under lldb, it prints correct output. How could this be?
I tried replacing the printf statements by “fprintf” to a file: same behaviour -
no file created and no output, but under lldb, the file
https://bugs.llvm.org/show_bug.cgi?id=43599
Bug ID: 43599
Summary: lldb can not print anonymous structs anymore
Product: lldb
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Prio
Pavel Labath said
> some llvm classes, are so well-known and widely used, that qualifying
> them with "llvm::" serves no useful purpose and only adds visual noise.
> I'm thinking here mainly of ADT classes like String/ArrayRef,
> Optional/Error, etc. I propose we stop explicitly qualifying thes
